feat: add tailwind showcase component.

[javieri-empathy]

Adds showcase components for the tailwind plugin.

• Updates vite to version 3
• Generates a new entry point for tailwind plugin: @empathyco/x-tailwindcss/showcase with the showcase components
• Configures build of this new entry point with rollup, as with Vite I found impossible to generate proper types in library mode.

[javieri-empathy]

We have to be very careful with this if moved to the archetype. With this line it will include the full set of components CSS. It should only be included for development purposes.

[tajespasarela]

Different configs for dev and for build can be a solution for this:
tailwindlabs/tailwindcss#9405

[javieri-empathy]

This is another proposal that I thought yesterday (yeah, I know, too late) about exposing a dev server rather than a set of Vue components.
In my mind this would allow us to remove the rollup config for the showcase components, it would facilitate using this from a custom project regardless the components library used, and also ease up this configuration (run a command instead of setting up a view and a development tailwind config).
https://searchbroker.atlassian.net/browse/EX-7329

[alvarodE]

I love how that sounds Javi :sisi3:

[alvarodE]

I'm wondering whether it makes sense or not to have a mixin covering all the logic that may be shared between different showcase components in the future. In the end I understand that sizes, colors, etc. apply to most of them, so my suggestion is something like this:

import { Vue, Component, Prop } from 'vue-property-decorator';

@Component
export default class XdsComponentShowcaseMixin extends Vue {
  @Prop({ required: true })
  public baseClass!: string;

  @Prop({ default: () => ['xs', 'sm', 'md', 'lg', 'xl'] })
  public sizes!: string[];

  @Prop({
    default: () => [
      'neutral',
      'lead',
      'auxiliary',
      'accent',
      'highlight',
      'success',
      'warning',
      'error'
    ]
  })
  public colors!: string[];

  @Prop()
  public combinations!: string[];

  protected get sections(): Record<string, string[]> {
    return {
      Default: [this.baseClass],
      Colors: this.colors.map(this.prefixWith(this.baseClass)),
      Sizes: this.sizes.map(this.prefixWith(this.baseClass)),
      ...(this.combinations && {
        Combinations: this.combinations.map(this.prefixWith(this.baseClass))
      })
    };
  }

  protected prefixWith(prefix: string): (value: string) => string {
    return cssClass => `${prefix} ${prefix}-${cssClass}`;
  }
}

[diegopf]

I think @alvarodE comment makes sense. Another option is to create a generic component that receives via props the configuration. The showcase component could get the tailwind config via resolveConfig so we have the prefix and colors. Afterwards a generic xds-component could just paint the given config. Something like

// Showcase component
    mounted(): void {
      const config = resolveConfig(this.tailwindConfigFile);
      this.colors = config.theme?.colors ?? {};
      this.prefix = config.prefix ??  '';
    }

  <div>
    <h3>{{ componentConfig.tag }}</h3>
    <ul>
      <li v-for="(_, colorName) in tailwindConfig.colors" :key="colorName">
        <component
          :is="componentConfig.tag"
          :class="[
            `${tailwindConfig.prefix}${componentConfig.base}-${colorName}`,
            componentConfig.classes
          ]"
        >
          {{ colorName }}
        </component>
      </li>
    </ul>
  </div>
</template>

<script lang="ts">
  import { Component, Prop, Vue } from 'vue-property-decorator';
  @Component
  export default class XdsItem extends Vue {
    @Prop({
      required: true
    })
    public tailwindConfig!: {
      prefix: string;
      colors: Record<string, object>;
    };
    @Prop({
      required: true
    })
    public componentConfig!: {
      tag: string;
      base: string;
      classes: string;
    };
  }
</script>

In the example above only colors are displayed but I think the point is clear 😅

[javieri-empathy]

I thought about those 2 approaches. But it is something I decided not to do in this PR because of early abstractions. I don't have a clear visibility of what would be helpful for each component that we design. So until we have 2-3 more components I wouldn't abstract the utilities to generate this showcase.

[diegopf]

Good job! As we discussed with @tajespasarela earlier I think it could be fine to merge this approach and just rethink it afterwards when we need to include another component in the showcase.

[diegopf]

I think @alvarodE comment makes sense. Another option is to create a generic component that receives via props the configuration. The showcase component could get the tailwind config via resolveConfig so we have the prefix and colors. Afterwards a generic xds-component could just paint the given config. Something like

// Showcase component
    mounted(): void {
      const config = resolveConfig(this.tailwindConfigFile);
      this.colors = config.theme?.colors ?? {};
      this.prefix = config.prefix ??  '';
    }

  <div>
    <h3>{{ componentConfig.tag }}</h3>
    <ul>
      <li v-for="(_, colorName) in tailwindConfig.colors" :key="colorName">
        <component
          :is="componentConfig.tag"
          :class="[
            `${tailwindConfig.prefix}${componentConfig.base}-${colorName}`,
            componentConfig.classes
          ]"
        >
          {{ colorName }}
        </component>
      </li>
    </ul>
  </div>
</template>

<script lang="ts">
  import { Component, Prop, Vue } from 'vue-property-decorator';
  @Component
  export default class XdsItem extends Vue {
    @Prop({
      required: true
    })
    public tailwindConfig!: {
      prefix: string;
      colors: Record<string, object>;
    };
    @Prop({
      required: true
    })
    public componentConfig!: {
      tag: string;
      base: string;
      classes: string;
    };
  }
</script>

In the example above only colors are displayed but I think the point is clear 😅

[alvarodE]

With the last merge of main into this branch there are a lot of changes on the doc files that I think we should discard. Is it because of the Prettier or something? @javieri-empathy

[javieri-empathy]

Fuck, I can promise you I didn't format them intentionally. I'm looking at them and I can tell you they some of them were not properly formatted, but there are also some changes that do not make sense, like moving titles to the previous line. My bet is that when merging main branch changes prettier decided to format them.