@jacobadeutsch

kristen pol → credited jacobadeutsch → .

kristen pol → credited jacobadeutsch → .

jacobadeutsch → made their first commit to this issue’s fork.

kristen pol → credited jacobadeutsch → .

kristen pol → credited jacobadeutsch → .

jacobadeutsch → made their first commit to this issue’s fork.

I think it depends on how we see examples being used. If we're able to successfully get an example's content working in referenced to included props without them being present in the yml then we don't need to include included props.

jacobadeutsch → made their first commit to this issue’s fork.

kristen pol → credited jacobadeutsch → .

kristen pol → credited jacobadeutsch → .

jacobadeutsch → made their first commit to this issue’s fork.

kristen pol → credited jacobadeutsch → .

kristen pol → credited jacobadeutsch → .

jacobadeutsch → made their first commit to this issue’s fork.

could add date formats, uri formats, min/max for int. image format should be checked with the XB team

fixed 4 small remaining errors, they're showing up in XB now!

got rid of attributes, corrected the errors above, and used yamllint to find and correct some other errors

Instructions were clear and I got XB running and everything. Not sure if the themes were working though, seemed like maybe they weren't.

fixed some yml enum mistakes that should have been previously resolved

kristen pol → credited jacobadeutsch → .

kristen pol → credited jacobadeutsch → .

kristen pol → credited jacobadeutsch → .

kristen pol → credited jacobadeutsch → .

kristen pol → credited jacobadeutsch → .

fixed the required fields thing

jacobadeutsch → made their first commit to this issue’s fork.

Nevermind lets not do this, most vars act the same like null, false, and '', but 0 works differently and removing these things could mess something up. It seems like these "errors" might just be warnings

MR for updated twigs. Mostly fixed UI Patterns error "The exact same as just testing the variable, empty is not needed." by removing "is not empty"

kristen pol → credited jacobadeutsch → .

kristen pol → credited jacobadeutsch → .

kristen pol → credited jacobadeutsch → .

kristen pol → credited jacobadeutsch → .

I went through and fixed most of the remaining stuff manually. The READMEs all had this error: 8:81 MD013/line-length Line length [Expected: 80; Actual: 156] and I just split that line into two. So that's one thing the generator script could have a small update on. Other than that I also fixed some line length problems in yaml files like label for example: 41:81 error line too long (81 > 80 characters) (line-length) where I used this notation to properly format it:

Key: >
  this is my very very very
  long string

From this webpage.

Which the generator could also be updated on. Other than that I just fixed some twig problems the linter exposed so we seem pretty good for now.

Here's the related issue:
https://www.drupal.org/project/demo_design_system/issues/3467234 📌 Use SDC conversion script to create baseline SDC YAML and README files Fixed

Here is the current version of the megalinter, it runs in the demo design system directory and can take a directory as an argument, but it defaults to the components dir and the starshot_demo/components dir

Generated ymls and mds using the twig-sdc-yaml-generator, fixed some twig problems, and some errors found while linting.

jacobadeutsch → created an issue.

kristen pol → credited jacobadeutsch → .

Here's a list of all of current yamllint and markdownlint errors and their associated files. I recommend turning this back into a json so it looks nicer, it wouldn't let me upload json. This is from a script I've almost finished the first iteration of, I could have it out to use by tomorrow if I'm able to meet with Kristen enough by then. Not sure though because she's at a conference right now.

Updated twig variables, mainly fixing issues where the enum format was wrong.

Ex:

With left, right or both.
->
Variable name: left, right, both.

jacobadeutsch → made their first commit to this issue’s fork.

Kristen Pol → credited jacobadeutsch → .

Additionally, there are 24625 problems (24625 errors, 0 warnings) for Javascript files under demo_design_system. Those files being:

civictheme_starter_kit/gulpfile.js
dist/civictheme.js
starshot_demo/components_combined/00-base/starshot-container/starshot-container.stories.js
starshot_demo/components_combined/00-base/starshot-one-col/starshot-one-col.stories.js
starshot_demo/components_combined/00-base/starshot-three-col/starshot-three-col.stories.js
starshot_demo/dist/scripts.js
starshot_demo/gulpfile.js
theme-settings/civictheme.theme-settings.colors.js

Found all of the problem files:

dist/civictheme.admin.css
dist/civictheme.css
dist/civictheme.editor.css
dist/civictheme.layout.css
dist/civictheme.variables.css
theme-settings/civictheme.theme-settings.colors.css
starshot_demo/dist/styles.css
starshot_demo/dist/styles.editor.css
starshot_demo/dist/styles.variables.css

found the other errors. they're all in theme-settings/civictheme.theme-settings.colors.css

34009 of these errors seem to be from demo_design_system/starshot_demo/dist
32693 of these errors seem to be from demo_design_system/dist

So 66702 out of 66722 of the errors are from both dist directories. I reckon it'll be easier to find the remaining 20 once those directories are dealt with.

jacobadeutsch → created an issue.

Most of the boolean problems seemed fixed but I did come across a weird edge case:

mobile-navigation-menu.component.yml

name: Mobile navigation menu

status: experimental

group: Organisms

props:

  type: object

  properties:
    theme:
      type: string
      title: Theme
      description: 'Theme: light, dark.'
      default: light
      enum:
        - light
        - dark

    items:
      type: array
      title: Items
      description: 'Menu links array. Each item contains:'
      items:
        type: object

        properties:
          title:
            type: string
            title: Title
            description: The title of the link.

          url:
            type: string
            title: Url
            description: The link url.

          below:
            type: array
            title: Below
            description: Array of submenu items.

          is_expanded:
            type: boolean
            title: Is expanded
            description: Flag if the current item has visible child.

          in_active_trail:
            type: boolean
            title: In active trail
            description: Flag if the current item is in the active trail.

I wish I knew more about yml to understand how this file is working better... The items are being nested twice or something? Coding this all seems like a pain, thank you for doing such a great job

I found a variable in the campaign component yml which isn't directly taken from the twig:

          type:
            type: string
            title: Type
            description: 'Button type: primary, secondary, tertiary.'
            default: null
            enum:
            - primary
            - secondary
            - tertiary

the twig comment:

{#
/**
 * @file
 * Campaign component.
 *
 * Variables:
 * - content_top: [string] Content slot.
 * - image: [object] Image object:
 *   - url: [string] Image URL.
 *   - alt: [string] Image alt text.
 * - image_position: [string] Image position: left, right.
 * - tags: [array] Array of tags.
 * - title: [string] Title.
 * - date: [string] Date.
 * - content: [string] Content.
 * - links: [array] Array of link objects containing:
 *   - text: [string] Link text.
 *   - url: [string] Link URL.
 *   - is_new_window: [boolean] Open link in the new window.
 *   - is_external: [boolean] Link is external.
 * - content_bottom: [string] Content slot.
 * - theme: [string] Theme: light, dark.
 * - vertical_spacing: [string] With top, bottom or both vertical spaces.
 * - attributes: [string] Additional attributes.
 * - modifier_class: [string] Additional classes.
 */
#}

This I think is because this type var is being taken from the button component which is included here in the twig:

										{% include '@atoms/button/button.twig' with {
											theme: theme,
											kind: 'link',
											type: loop.index == 1 ? 'primary' : 'tertiary',
											text: link.text,
											url: link.url,
											is_new_window: link.is_new_window,
											is_external: link.is_external
										} only %}

To be honest I have no idea if this is supposed to be how it is, so just double checking here.

I think any instances of duplicate enums would be because the twig files have a mistake in them. So I wouldn't think it's 100% necessary for the script to do that. Seeing that mistake in the yml helps us find the problem in the twig as well.

In the button component, the yml file was generated with a null default for this var:

    type:
      type: string
      title: Type
      description: 'Button type: primary, secondary, tertiary.'
      default: null
      enum:
      - primary
      - secondary
      - tertiary

I think it's getting that from here:
{% set type = type in ['primary', 'secondary', 'tertiary'] ? type : null %}

Should it just not have a default in this instance? Maybe default: null is right here, I'm not really sure.

Another thing, booleans that appear under objects don't go by the title: description formatting. Here's an example from the list organism:

...
    link_above:
      type: object
      title: Link above
      description: 'Link object:'

      properties:
        text:
          type: string
          title: Text
          description: Text.

        url:
          type: string
          title: Url
          description: URL.

        is_new_window:
          type: boolean
          title: Is new window
          description: Open link in a new window.
...

Kristen Pol → credited jacobadeutsch → .

Kristen Pol → credited jacobadeutsch → .

The script is seriously awesome now, great job!

I'm working on creating the baseline ymls using it rn, and I did encounter a small problem:

    description_display:
      type: string
      title: Description display
      description: 'Description display: before, after, invisible. Default is before.
        Optional.'

      default: before
      enum:
      - before
      - after
      - invisible. Default is before. Optional



    message_type:
      type: string
      title: Message type
      description: 'Type of the message: error, warning, info, success. Default is
        error.'

      default: error
      enum:
      - error
      - warning
      - info
      - success. Default is error

I guess this is one thing I missed about the formatting of the twigs, there can be a default specified after the list. I think there should be at least a . at the end in these instances, so maybe first it can check for a . and then a \n just incase there isn't a . at the end? I'm not great with regex but I hope the solution is pretty simple. Not sure what happened with the indents either but idk if that will be a problem with the syntax.

Kristen Pol → credited jacobadeutsch → .

Kristen Pol → credited jacobadeutsch → .

I've attached an instance of the enum not being generated from the OLD twig-sdc-yaml-generator below. The new script generated the enums fine.

    type:
      type: string
      title: Type
      description: 'Type: primary, secondary, tertiary'
      default: primary

If instead of generating based on a given list of hardcoded enums you wanted to create a text parser to generate them I think there is a standard procedure for writing the twigs that could make this possible:

 * - theme: [string] Theme: light, dark.
 * - type: [string] Type: primary, secondary, tertiary
 * - icon_placement: [string] Icon position: before, after.

* Not sure if a . at the end is standard, or if this twig has a typo and that's what caused the problem

I think this is standard? * - var_name: [string] Name: enum1, enum2, enum3, enum4, etc...

Maybe the second colon in the line could be used to detect a list of enums? I guess I might be missing other cases.. I don't remember if objects or arrays sometimes include a colon in their descriptions, and I guess if they did then a way around that could be checking the datatype first. Assuming all enum lists are of type string.

Other than that though I think the only notes I have are that spacing between the vars would be nice. Something like this:

name: tag

status: experimental

group: Atoms

props:

  type: object

  required:
  - content
  - url

  properties:

    theme:
      type: string
      title: Theme
      description: 'Theme: light, dark.'
      default: light
      enum:
      - light
      - dark

    type:
      type: string
      title: Type
      description: 'Type: primary, secondary, tertiary'
      default: primary
      enum:
      - primary
      - secondary
      - tertiary

    content:
      type: string
      title: Content
      description: Content.

Also group names are showing up as "default" right now. And the blank string bool defaults are still appearing but I assume you're on that.

Great work!!

should be ready to merge

Kristen Pol → credited jacobadeutsch → .

To update the twig:

{#
/**
 * @file
 * Starshot one column component.
 *
 * Variables:
 * - column_one: [string] First column slot.
 */
#}

{% set column_one %}
  {% block column_one %}
  {% endblock %}
{% endset %}

{% include '@base/grid/grid.twig' with {
  items: [column_one],
  column_class: 'col-xxs-12',
  row_class: 'row--equal-heights-content row--vertically-spaced',
} only %}

Not sure if default: null works but other than that here's some yml

Fixed another typo:
* - type: [string] Button type: primary, primary, secondary, tertiary.

did it

jacobadeutsch → created an issue.

Here's an initial yml file.

You're right it should be more like this:

{#
/**
 * @file
 * Starshot three column component.
 *
 * Variables:
 * - column_one: [string] First column slot.
 * - column_two: [string] Second column slot.
 * - column_three: [string] Third column slot.
 */
#}

or this:

{#
/**
 * @file
 * Starshot three column component.
 *
 * Variables:
 * - column_one: [string] Column slot.
 * - column_two: [string] Column slot.
 * - column_three: [string] Column slot.
 */
#}

Here's a cleaned up version. The required section might be wrong since it was generated. With higher complexity components like this the need for a standard procedure increases, it's a lot easier for little mistakes to go unnoticed with organisms like this

Cleaned up the file. Should be usable, still not perfect since we don't have a standard practice to go by.

Oh yeah I felt like the converter was missing something at the top, of course. I changed it and reattached. I'm not sure how the converter determines what is required...

Looks good to me. I know the order doesn't matter but it's pretty common to see the theme as the first variable, but this should work.

This should be more correct I think:

{#
/**
 * @file
 * Starshot Heading component.
 *
 * Variables:
 * - theme: [string] Theme: light, dark.
 * - content: [string] Heading content.
 * - level: [string] Semantic level: 1, 2, 3, 4, 5, 6.
 * - display: [string] Font style of heading: drupal-2, drupal-3, drupal-4, drupal-5, drupal-6, drupal-7, drupal-8.
 * - align: [string] Heading alignment: left, right, center.
 * - attributes: [string] Additional attributes.
 * - modifier_class: [string] Additional classes.
 */
#}

I used the converted to create a base yml file then cleaned it up a bit.

Some notes for the converter:
- Booleans need to be changed to have their title as the description for the boolean.
- Should the defaults be displayed in the yml?
- The converter didn't create a enums where it should've
- Not everything with a space in it has quotes around it, not sure if this is necessary or not
- it included a blank default for a boolean.. it seems like that it's getting that from line 27 of the twig. I deleted it because I wasn't seeing defaults for other bools, but this could be wrong

Not 100% sure if

{% include '@base/grid/grid.twig' with {
  items: [column_one, column_two, column_three],
  column_class: 'col-xxs-12 col-l-4',
  row_class: 'row--equal-heights-content row--vertically-spaced',
} only %}

should be represented in the yml in any way. But if it shouldn't then the attached yml should work I think.

Should the twig be updated like this to include the slot info in the comment?:

{#
/**
 * @file
 * Starshot three column component.
 *
 * Variables:
 * - column_one: [string] First column.
 * - column_two: [string] Second column.
 * - column_three: [string] Third column.
 */
#}

{% set column_one %}
  {% block column_one %}
  {% endblock %}
{% endset %}

{% set column_two %}
  {% block column_two %}
  {% endblock %}
{% endset %}

{% set column_three %}
  {% block column_three %}
  {% endblock %}
{% endset %}

{% include '@base/grid/grid.twig' with {
  items: [column_one, column_two, column_three],
  column_class: 'col-xxs-12 col-l-4',
  row_class: 'row--equal-heights-content row--vertically-spaced',
} only %}

Here's an updated twig:

/**
 * @file
 * Card component.
 *
 * Variables:
 * - theme: [string] Theme: light, dark.
 * - display: [string] Card display: vertical, horizontal, centered, overlay.
 * - title: [string] Card title.
 * - summary: [string] Card summary.
 * - link: [object] Link object:
 *    - text: [string] Text for the link.
 *    - url: [string] URL for the link.
 *    - is_external: [boolean] Link is external or not.
 * - background: [string] URL for the background image.
 * - tags: [array] Tags array:
 *   - icon: [string] Icon name.
 *   - content: [string] Tag text.
 *   - icon_placement: [string] Icon position: left, right.
 *   - url: [string] URL for the link.
 *   - is_new_window: [boolean] Open link in a new window.
 *   - is_external: [boolean] Link is external or not.
 * - image: [object] Image object:
 *    - url: [string] URL for the image.
 *    - alt: [string] Image alt text.
 * - attributes: [string] Additional attributes.
 * - modifier_class: [string] Additional classes.
 */

I based this off of various other component's twigs. I'm not sure if anything else has to be added for this component in particular, but this should work better for now.

I had to shrink the dimensions as well as using pngquant, and it's still too big. I think from what I've learned gradients are really annoying to compress, and often can't be compressed as much as you'd think. If it was a single blue to magenta gradient going upward it might compress better. Even having 3 colors might be okay as long as it lays flat with the horizon.

I tested out the script in these issues:

https://www.drupal.org/project/demo_design_system/issues/3465333 📌 SDDS SDC Conversion Examples: Map component [MANUAL] Postponed
https://www.drupal.org/project/demo_design_system/issues/3465336 📌 SDDS SDC Conversion Examples: Banner component [MANUAL] Active

So far so good :)

Tested python script on this one and it worked. Attached files.

I tested the qed42 twig sdc yaml python script on this one and it worked. I attached the result below. Better formatting for it would be nice though, it'd make it easier for people to review the yml.

I made a prototype for an AI version and it seems like it might be even more tedious to fine tune the prompt for it. I think for now we should just use the algorithm, it'll be more consistent in the end anyways. I've attached the python script as well as its result here. It didn't do super well.

Kristen Pol → credited jacobadeutsch → .

I tested the converter in this issue:
https://www.drupal.org/project/demo_design_system/issues/3465318 📌 SDDS SDC Conversion Examples: Chip component [MANUAL] Active

My main thoughts so far is that I'd like the yml files to be more readable. Putting empty lines between the variables would be helpful.

Also I think we should always put double quotes around descriptions and titles:

here's a bit from the generated yml:

    size:
      type: string
      title: Size
      description: 'Chip size: large, regular, small.'
      default: regular
...
    is_selected:
      type: boolean
      title: Is selected
      description: Is the button selected (for filter chips).

Also in the conversion guide: https://www.drupal.org/community-initiatives/starshot-demo-design-system... →
It seems like we might want to only have titles for booleans like this:

    is_selected:
      type: boolean
      title: "Is the button selected (for filter chips)."

This is because for these checkboxes the title is the bit that's going to be displayed to the user and this makes more sense for that.

Also I tested ChatGPT to see if it could potentially be used along with a Python script to generate yml and it seems like it could.

My phpcs isn't showing any problems anymore for what the Python script generated. It was probably just a problem on my end. Since the script works on this one I'm going to test it on a molecule and an organism.

Here's my basic chip yml file for testing and comparison. It would be good to come up with a standardized procedure for converting the twigs to yml. The conversion guide helped me out but left some stuff ambiguous, like how the titles should be generated, etc.

The Python script as of right now doesn't do the formatting right. The spacing is incorrect along with the way it does enums. Also includes the "default" for enums. I've attached the chip yml file I generated with the script below.

ChatGPT initial test:
https://chatgpt.com/share/9fbea4c3-d260-4fd0-ab54-05a56064ae02

Definitely could be possible to create a script using the ChatGPT api for this, it's already 90% of the way there. Not sure if it's less efficient than using our own python algorithm though.

* UI Suite checker and XB tests are still pending
* I've also attached a screenshot of an error on the registry component audit page

Kristen Pol → credited jacobadeutsch → .

Kristen Pol → credited jacobadeutsch → .

Kristen Pol → credited jacobadeutsch → .

Kristen Pol → credited jacobadeutsch → .

Kristen Pol → credited jacobadeutsch → .

Kristen Pol → credited jacobadeutsch → .

I can't seem to compress it beyond 16KB because of the logo I added.

here's a logo

here's a logo

here's a logo

here's a logo

here's a logo

here's a logo that incorporates the base logo for paragraphs

here's a logo

here's a logo