Publish Storybook 📖

[camelPhonso]

Expected Behavior

Contributors, including non-coding contributors, should be able to easily see the most up-to-date version of our component library.

By publishing storybook to github pages with Continuous Deployment via github actions we can give everyone 'one-click' access to the library for the dev branch

Current Behavior

Contributing to and updating the component library is already a part of the expectations for PR's but we are not using this to communicate with non-coding contributors in the community.

Any other notes

This Issue will help us streamline a lot of the work planned for 'v2'

Assignment

This issue is free for anyone to take

[mnixo]

!request

[github-actions[bot]]

🤖 meep morp!

Thank you for your contribution @mnixo - this Issue is assigned to you as requested ✨

🔎 Please keep in mind that in order to give everyone a chance to contribute Issues may be unassigned if they go stale. You will be warned if the Issue is marked as stale at any point.

🔎 Please review our documentation for guidance on:

• common Patterns we follow in the code base
• conventions set for commit messages and naming of functions, classes or files

💡 The core team is available for any help and will try to respond to any comments in this Issue or questions on discord as quickly as possible.

Happy coding ! 🦆

[RGHANILOO]

I agree that contributors need easy access to the latest version of the component library. Publishing Storybook to GHP would be a great first step for the dev branch.

To further enhance component management and documentation, consider building a lightweight component library. This library could use:

Storybook: Isolate and visually document each component. Tailwind CSS: Style components efficiently with utility classes. Importantly, ensure the library complies with web accessibility requirements WCAG for inclusive design .

This approach offers a handful of benefits:

• Single Source of Truth (SST): Maintain a central repository for component code, styles, and documentation.
• Improved Maintainability: Easier to manage and update components independently.
• Reusable UI: Facilitate the creation of consistent and reusable UI components across projects. Publishing on npm:

We could publish the library as @kyndly/ui on npm, allowing for easy integration into the main project using imports like import { nav } from @kyndly/ui.

[mnixo]

I just opened a PR for this one.

@RGHANILOO, I'm going to stick with the original scope of the issue on this one. There are definitely several improvements we could work on in this context, but I think each of them would deserve its own issue and they should be reviewed by the team. Plus, with the creation and publishing a component library comes the responsibility of maintaining it. This is a pretty serious responsibility and given the current use case for these components I don't really think it's necessary.