[WIP] [FEAT] Add Storybook to maintain Chapter's Design System

[phoenisx]

• I have read Chapter's contributing guidelines.
• My pull request has a descriptive title (not a vague title like Update README.md).
• My pull request targets the master branch of Chapter.

Closes #301

Storybook PR

To see the end results of Storybook Docs, checkout official Design System by Storybook

Why??

• Storybook promotes Component Driven Development
  and allows to present UI Components in an interactive Design System.
• Various Storybook addon promotes better Styled Component code, as it isolates the Component development from logic.
  • addon-a11y promotes accessibility based development for UI components
  • addon-backgrounds helps us to develop various themes for the app, based on how they look in dark/light backgrounds.
  • addon-viewport helps developing components keeping viewport in mind.
• Documenting UI Components.
• Automated Visual Testing

I like storybook because it forces to keep UI Components separate and re-usable, so that as when designs changes, it's easier to change Designs for a Component and reflects across the whole app. Following this way also promotes better Component Composition.

Some More References:

• https://blog.bitsrc.io/building-a-consistent-ui-design-system-4481fb37470f
• https://github.com/storybookjs/design-system

v3 of Storybook would be even more awesome, with better MDX support and hopefully better auto documentation support for typescript components.

Issues:

• Storybook Compatibility with NextJS Routers is not yet perfect. Thus to resolve it, I had to add stubbed router .A good suggested solution around this for now is in detailed dicussions here and here
• Sometimes Addons Panel might not be visible, to resolve this - Addons panel not showing - but knobs are still working(?) storybookjs/storybook#8383
• I have used Google's Brand Icon (svg) to create Login Button. As per brand guidelines, we have to rethink the way Google Signin button should be designed.
• Typescript React Docgen is not yet properly compatible with storybook docs, thus, auto proptypes are not loaded yet.
  • Still we can use Storybook components / Or Docs Table to document it by ourselves.
• I haven't added proper theme to Storybook to support Chapter's own theme yet.

NOTE:

• Storybook Compilation has become pretty slow, due to too many Material-UI deps and also due to react-docgen-typescript
• Adding Storybook is not part of Chapter's MVP. It will be an ongoing process of development, where devs can code the Components referencing Figma Design, add component docs and re-use Components across the App.

This PR is in progress, and am trying to integrate Storybook's Storyshot for Auto Visual Testing

[allella]

Probably worth having the design side aware of this as well. Pinging @madaleneaza-design @vkWeb

[Madalena-15]

I am unfamiliar with Storybook (as well as any coding that is beyond CSS level) but I did a quick research on how it works and like the idea of it.

As we are still in the discovery and ideas stage (I believe), this is brilliant that you have set this up, so when we get to the high-fidelity/final prototyping stage and look more into this. 🙂

I hope this somehow helps, but I believe @vkWeb would be the best person to discuss anything on the technical side

[vkWeb]

@Shub1427 I have replied in detail about this in Discord. Copying from there:

You have put a lot of work there. I appreciate your work :) I have almost zero experience with React so I won't comment / review it. I am just writing some of my concerns after reading a bit about storybook.

I think we should not make things complicated, things should be straightforward for our design team to smoothly sail. Figma is working fine. We design in Figma and share the link. Then devs can implement those designs. The Figma designs are basis upon which our devs implement, it's not we "must" do it that away, devs can make suitable changes in the design if they feel.

Once MVP is shipped, for the majority of the time we will be implementing new features and refining the existing UI. I see figma fading away at that point unless we plan to do a total UI rehaul.

Also, we are using Material, we don't have our own design system in place so IMO it's better not to implement Storybook. Though I clearly see its advantage for heavy UI apps.

@shub1427 From your messages on Discord:

I know we are already using Material UI for most of our Base Components, but still there are always chances to have custom components that gets derived from such design components, and shared among various pages.

We won't have many custom components I believe. Only event and chapter cards are designed by our team. Everything else is from Material with our palette on it.

Storybook will help in managing such Components and give developers a single source of truth for design components that Chapter uses, can re-use them or add more if needed.

I think React components can be reused, right? So why we we should use storybook? I don't know if this makes sense.

[phoenisx]

I guess u misunderstood my statement @vkWeb .

Storybook is nothing but a way of documenting UI, the way Swagger works for API, giving few more extra features like structural testing and stuff. It's just a Wrapper around React Components, not replacing it.

Anyways I get ur point, it seems correct not to use it, as we might be using Material UI extensively. Will close the PR for now, if ever the requirement arises, do let me know, will open and add Storyshots to the PR as well. 👍

[vkWeb]

@shub1427 Sure. If we find needs of storybook in future we will definitely point you ;)

Thanks for your work brother. I feel bad that you had to close this PR after so much work. Anyways we can open this PR later and build upon existing code :)