Setup storybook for Porter dashboard

[modularcoder]

Pull request type

Please check the type of change your PR introduces:

• [ ] Bugfix
• [x] Feature
• [ ] Other (please describe):

Pull request checklist

Please check if your PR fulfills the following requirements:

• [ ] If it's a backend change, tests for the changes have been added and go test ./... runs successfully from the root folder.
• [x] If it's a frontend change, Prettier has been run
• [ ] Docs have been reviewed and added / updated if needed

What is the current behavior?

No storybook. Components need to be developed while running applications

Issue Number: N/A

-->

What is the new behavior?

Installed storybook and added a few stories for Button component. Having storybook in the project allows to develop App parts/atomic elements in isolation describing their different states. This might be also useful for moving to component-driven-development.

Technical Spec/Implementation Notes

• Added storybook configs to dashboard/.storybook
• Added "start:storybook" script which runs the storybook on port 8082
• Added storybook with Vite builder and a few essential deps
• Customized storybook theme to be dark and have same BG color that porter APP

[joshuaharry]

Do we want to invest the engineering resources to migrate all components to Storybook? There might be other technical debt that might be a higher priority first. Ultimately, it's not necessarily a bad way to go—I've used Storybook when writing component libraries at a startup before—but maintaining it takes significant time and energy, and I think there could be quicker, higher-impact wins available.

The final call on that should probably go to the maintainers of the app; I do think the tradeoffs here are worth considering. Regardless, @modularcoder, I think it's amazing that you got from 0 to 1 so fast!

[modularcoder]

Do we want to invest the engineering resources to migrate all components to Storybook? There might be other technical debt that might be a higher priority first. Ultimately, it's not necessarily a bad way to go—I've used Storybook when writing component libraries at a startup before—but maintaining it takes significant time and energy, and I think there could be quicker, higher-impact wins available.

The final call on that should probably go to the maintainers of the app; I do think the tradeoffs here are worth considering. Regardless, @modularcoder, I think it's amazing that you got from 0 to 1 so fast!

Yeah, implementing a custom component library and a design system is taking quite a lots of efforts, but there are already huge amount of components built, might be useful to document those.

On the other hand what I've seen in the code is quite far from a proper design system, and implementing one might be really time consuming.

Storybook on the other hand allows to develop the components in isolation, but that will require a paradigm shift from how It's done at the moment, separating components to pure visual components and smart components which make the API calls. In a long run that gives some fruits because the APP can be developed on top of tested and described components. Then those visual components might be embedded into Figma via Storybook Connect and chromatic plugin, which improves FE <> Design teams collaboration a lot.

But yeah, it takes lots of efforts :)