itemconsulting / enonic-ts-codegen Goto Github PK

It should be investigated if Checkbox input type can return undefined. If not the interface should always be boolean, and not boolean | undefined.

When generating types from our XML, any input type using the Enonic type tag will generate an interface for a string, but tags are stored as a string only on single values, otherwise it is an array of strings.

What we have:

<input name="tags" type="Tag">
     <label>Tags</label>
     <occurrences minimum="0" maximum="0"/>
</input>

What we get:

  /**
   * Tags
   */
  tags?: string;

Need to add quotes around props with dashes

Macros also have xml's that can be read and generated interfaces from.

Need support for option-set: https://developer.enonic.com/docs/xp/stable/cms/schemas#optionset

OptionSets can be used within ItemSets.

The type of ItemSets are T | Array<T> | undefined, when it would be easier to work with them if they were just Array<T>, but then we have to do forceArray on them, and the interfaces are still not improved.

Could we use a flag in tye .enonic-file that renders out ItemSet-interfaces as Array<T>, and also a list of fieldNames that are ItemSets.

That way we can automatically iterate over the fieldNames, and fix with forceArray.

Old:

export interface Article {
  myField?: Array<{
    name: string;
  }>
}

New:

export interface Article {
  myField: Array<{
    name: string;
  }>
}

export itemSetFieldNames = ['myField']

We can then in enonic-wizardry create something that can be used like this:

import {Article,itemSetFieldNames} from '../../content-types/article/article.ts';
const query = getQueryer<Article>(itemSetFieldNames);

query({
  ...
})

Input xml:

<input name="invite" type="ComboBox">
  <label>Invitert</label>
  <occurrences minimum="0" maximum="1"/>
  <config>
    <option value="Ja">Ja</option>
    <option value="Nei">Nei</option>
    <option value="Kvalifisering">Kvalifisering</option>
  </config>
</input>

Output ts:

export interface Soknad {
  invite?: "Ja" | "Nei" | "Kvalifisering";
}

Amazing library, we use it and it helps us a lot. However, we would love for it to support a not very uncommon scenario: mixins within mixins. It is in cases where we store only a few fields (like a kind-of heavily configured ImageSelector) in a mixin, and then use this one in other, larger, mixins. This is not supported in the generator today, so it ends up like mixinName: mixin, in the generated code.

Could mixins be resolved recursively, and at the very beginning before all types are resolved?

Example Content Type, followed by example mixin level 1, and example mixin level 2:

Content Type:

article.xml

<?xml version="1.0" encoding="UTF-8"?>
<content-type>
    <display-name>Page: Article</display-name>
    <display-name-label>Title</display-name-label>
    <description>Used for writing articles, blogposts, product info.</description>
    <super-type>base:structured</super-type>
    <is-abstract>false</is-abstract>
    <is-final>false</is-final>
    <is-built-in>false</is-built-in>
    <allow-child-content>true</allow-child-content>
    <form>
        <field-set>
            <label>Article</label>
            <items>
                <mixin name="common"></mixin>
            </items>
        </field-set>
   </form>
</content-type>

Mixin Lvl 1

common.xml

<mixin>
  <display-name>Common</display-name>
  <form>
    <input name="title" type="TextLine">
      <label>Title</label>
      <occurrences minimum="0" maximum="1"/>
    </input>
    <input name="preface" type="TextArea">
      <label>Preface</label>
      <occurrences minimum="0" maximum="1"/>
    </input>
    <mixin name="optional-image"/>
  </form>
</mixin>

Mixin Lvl 2

optional-image.xml

<mixin>
    <display-name>Optional Image</display-name>
    <form>
        <option-set name="imageSelector">
            <!-- Too large of a form to include here ... but this structure should give you an idea. -->
        </option-set>
    </form>
</mixin>

When mixins are used inside the following:

• <item-set>
• <field-set>
• <option-set>

The mixins are not applied.

See enonic documentation on how to build example xml's.

Fields with the input type="Long" should generate an interface field with the type number.

https://developer.enonic.com/docs/xp/stable/cms/input-types#long

If we want to handle several types that uses the same mixin, a common interface that they all implement can be useful to have.

Checking against type="Checkbox" instead of type="CheckBox" gives the wrong type for the field, since this application enforces case sensitivity that Enonic does not.

See if a custom xml attribute can be used to disable code generation for a given component.

I hadn't specified whare the xml attribute is, but we should consider having a common prefix, if we add more custom xml attributes later.

Lets say we have the following mixin (/site/mixins/with-description/with-description.xml)

<mixin>
  <display-name>With Description</display-name>

  <form>
    <input name="description" type="TextLine">
      <label>Description</label>
      <occurrences minimum="0" maximum="1"/>
    </input>
  </form>
</mixin>

And it is being used in an content-type (article.xml):

<content-type>
  <display-name>Article</display-name>
  <super-type>base:structured</super-type>

  <form>
    <mixin name="with-description" />
  </form>
</content-type>

It will generate the following (wrong) interface:

export interface Article {
  /**
   * With Description
   */
  'with-description': {
    /**
     * Description
     */
    description?: string;
  };
}

The correct interface to generate would be this:

export interface Article {
  /**
   * Description
   */
  description?: string;
}

The option-set in the xml below is not generated:

<field-set>
    <label>Important header</label>
    <items>
      <option-set name="somethingoptionset"> <!-- not generated -->
        <label>options</label>
        <expanded>false</expanded>
        <occurrences minimum="0" maximum="1"/>
        <options minimum="1" maximum="1">
          <option>
          <option>
        </options>
      </option-set>
    </items>
<field-set>

An option-set inside an item-set inside a field-set is generated though.