Storybook integration proposal

[gaydabura]

PR: https://github.com/skilld-labs/ui-patterns-kaizen/pull/12

Goal is to implement storybook integrated in drupal as much as possible including patterns aswell.

Atoms

1. Atoms in storybook never must be a pattern. Atom is atomic entity, which should provide very basic html

Atom integrated in drupal on theme hook level. For all FormElements drupal allow use hook suggestion, like input__[type], eg input__password, etc. So we propose map atoms in drupal with hook_theme_registry_alter, on practice it requires file a-text-password.yml with next structure

a-password:
  hook: 'input__password'
  base hook: 'input'

In this case it allow us to use native storybook template, which works as suggestion during drupal render. read more: https://git.drupalcode.org/project/drupal/-/blob/9.5.1/core/lib/Drupal/Core/Theme/ThemeManager.php#L162

1.1. Atoms for RenderElement (which is not FormElement):

• In hook_element_info_alter we override some Elements info and extend #theme to work similar to FormElements, using __ to find parent theme implementation. So idea is to allow developer to list all basic RenderElements which should be overrided with theme atoms.

For now we hardcode suggestions here https://github.com/skilld-labs/ui-patterns-kaizen/pull/12/files#diff-01c746a587919a71b0d8563f0c5bf4c5a62175c3280f32d861cae81865d25190R154

In array we have [base_hook => new_hook] where base_hook is drupal core theme hook, and new_hook is a reference to specific atom. Naming convention is: [ [core_hook] => [corehook][atom_name] ] Example: ['select' => 'select__a_select'] Example: we want to rewrite select with a-select atom, so we need:

• in code https://github.com/skilld-labs/ui-patterns-kaizen/pull/12/files#diff-01c746a587919a71b0d8563f0c5bf4c5a62175c3280f32d861cae81865d25190R154
• in a-select.yml next code :

  a-select:
  hook: 'select__a_select'
  base hook: 'select'

Molecules

We apply similar approach here, but difference is that molecule itself is a wrapper to render few elements(atoms).

We still hardcode theme function https://github.com/skilld-labs/ui-patterns-kaizen/pull/12/files#diff-01c746a587919a71b0d8563f0c5bf4c5a62175c3280f32d861cae81865d25190R160

Example: https://github.com/skilld-labs/ui-patterns-kaizen/pull/12/files#diff-73b5349a6946385b41f21dec01fa755e7c9cf651c095eb13f585b967763beb8fR1

Todo

• Research better storage of rewrited theme hooks mapping: info.yml, config storage, anything else
• Research possible usage https://api.drupal.org/api/drupal/core!lib!Drupal!Component!FrontMatter!FrontMatter.php/class/FrontMatter

[iberdinsky-skilld]

https://github.com/skilld-labs/ui-patterns-kaizen/pull/12#issuecomment-1407724573

[gaydabura]

Just moved discussion here, please lets continue in issue.

#12 (comment)

• Could you please provide more possible use cases? Because form elements it is not main time-killer on projects.
• Form elements often use only one ATOM-INPUTTEXT.
• Why Atoms in storybook never must be a pattern ? Atoms need settings. For example Button or Title formatter will be very configurable. Atomic system shouldn't be broken because of Drupal requirements.

https://github.com/skilld-labs/ui-patterns-kaizen/pull/12#issuecomment-1407728394

@iberdinsky-skilld yes,

1. Next molecules may use hook_theme: menu, details, table, status, list, etc
2. Form element needs label+element also may need additional items, like icon, description, etc
3. Because atomits standalone item, first mistake - use it as pattern, second - atom similar to renderelement in drupal, its atomic item, with defined settings (from code), so no UI. You may change settings in case you are using render element from your custom code, so in case of atom (when it rewrite drupal renderelement) all possibilities will be available through native drupal render array 3.1. In case you need dynamic "settings" for atom, it stops being atom and become another level, eg molecul, whatever, smth which use atom with rewrited default settings.

[iberdinsky-skilld]

atom similar to renderelement in drupal https://xd.adobe.com/ideas/process/ui-design/atomic-design-principles-methodology-101/ it is design entity mostly and this change can be reason of misunderstandings

[gaydabura]

No, because as i said before:

• When you use RenderElement in drupal, you may set different attributes, or/and even custom properties
• Means that this approach may be applied on front aswell. So i dont see anything which does not fit into Atomic Design Principles & Methodology

[koskinpark]

Can you provide us examples with regular Atom Button and Atom Text we are using on every project? Both of these atoms are mostly just to display:

1. attributes
2. tag
3. content

It's pretty simple and clear in terms of atom's realisation. And both of these components were UI Patterns on eshopgen project. How to handle with it?

[koskinpark]

In terms of drupal -> Atom button can be input--submit.html.twig. But also can be a link, which is visually looking like a button -> a content link i mean <--- so here we are applying UI Pattern.

What i'm thinking is that this rule Atoms in storybook never must be a pattern should be no-go. It reduces visibility & worsen front-end development & rises entry level.

The thing is still the same i explained in production chat - we shouldn't have strict rules of doing components. Frontend (at least low-skill frontender) still should have an ability to do any trash inside of theme and it should be somehow "allowed", but not "denied". That's the same thing required as you are backender asking us to think what if i'll open my own render array.. Same here - what if frontender just can write simple html, css and js. From my pov it should be optional.

See here -> frontender is doing some shit in theme, but experienced backend guy want to re-use this component in drupal -> so backender can define its own yml config with base hook and so on -> and it will work in drupal with the help of backender. Once again - no strict rules please

But right now i'm thinking if a component can be a "mix" of UI Patterns & your strategy. We can have two yml files at least, or something -> where component can be UI PAttern and override of base hook at the same time.

====

Of course we will have a call, so you will explain better your idea.