Revisit component architecture? And add a design-system

[zkwsk]

This is an idea that's up in the air and I'd like some feedback on it... Might want to take it up dur

First watch this talk (app 30 min - and worth it):

https://www.youtube.com/watch?v=TqfbAXCCVwE&feature=youtu.be

Currently we try to enforce a flat "modular" structure of components. The challenge with this approach is that you easily end up wasting time trying to make components work in a modular fashion when they are never actually re-used and when you try to enforce too much re-use you can easily loose track of what components are depending on what components.

The gist of the talk is that it is recommended to apply some constraining principles in terms of dependencies and apply a layered approach and then to extract shared components out into a modular design system.

I have already described how you can do theming in the readme file, but it is rarely used or understood very well by the students. The thinking here is that we could create a basic design system with "atomic components" already defined as well as a file where we declare design tokens (i.e. theming variables) that we will then adjust based on project needs. The design system itself will be either in a separate repo and loaded as a npm package or in the same monorepo, but linked into the main project as a dependency, so modularity is enforced and so we can easily carry over improvements to the system itself from project to project. The design tokens will also be part of the design system, but there will be a local override file on a project-to-project basis.

In essence, this will make frontend work on final projects a little bit like customizing a wordpress theme or learning to use something like Google Material Design. Students will use some basic components as building blocks and these components will have some sensible styling applied to them from the beginning, but as the requirements grow, students will have to learn to combine and compose the provided components together into more complex components and in certain cases they may be asked to promote changes they've made into the design system, so we can easily retain them for later projects.

If we do this, I plan to write a detailed tutorial and probably record a video guide as well on how to work with the design system.

Pros:

• There will be a unified way to do styling and re-use of components that can be taught and improved from project to project.
• We could develop a unified design of "Hack Your Future" final projects over time and achieve a more unified visual appearance.
• If we have a framework like this in place, it takes away a lot of questions about what components are supposed to look like and allow us to focus more on building. Essentially the questions left will be: "How do we want the theming to be this time, color, spacing, etc.?". And "do we need to build/import some new components that we have not used before?"

Cons:

• It will be harder to "drop in" existing libraries, such as Google Material Design, Blueprint.js or similar. But we could also build all of this on top of an existing library, but then we would be married to that one library and it might come with some extra overhead in terms of learning how to use the components.

I'm not sure if I made myself understandable, or I'm just rambling, but let me know if something is unclear.