Synopsis

This page goes through each section discussed to see how feasible each topic would be for Team Obsidian.

TL;DR

Web Components

Effort Required (estimate based on 1 developer):
Three Quarters

Library Improvements

Effort Required (estimate based on 1 developer):
One Quarter

CSS Variables

Effort Required (estimate based on 1 developer):
Two / Three Sprints, depending on scope

Storybook

Effort Required (estimate based on 1 developer):
One Quarter

Web Components

There are pro's and con's to deciding if we should go with WC or not, so I think it's important to ask ourselves a few key questions:

  • Do we have adequate time to refactor our existing React codebase to WC? At this stage, I do not think we would have the resources available to refactor our existing codebase to use WC. As well as swapping out our React Component Library to a new WC Library, the majority of our tests inside Fusion would also need to be updated. This would create severe overhead for Team Obsidian, and that is before the actual creation and testing of a new WC Library in the first place.
  • Are we a "React" company? It would be advantageous to have a flexible technology stack on a per project basis instead of being constrained to one setup. Let's say we wanted to try VueJS, Svelte, or another UI Framework, are we in a position to do this? Currently, our project architecture is so deeply entwined in React that it's difficult to see us being in this position, especially as all of our packages are housed inside one huge monorepo instead of being micro-frontends. All of our routing and lazy-loading is handled via React also. The team at Flexera are also planning to refactor our legacy applications that were built in Angular to React codebases, so we will be even more deeply invested into the React ecosystem.
  • How do we future-proof ourselves? Members of Team Obsidian will know all too well that the world of Front-End changes at a rapid pace. The library we choose today will probably be out of fashion tomorrow. So try to imagine 2 or 3 years from now - what position do we want to find ourselves in? I understand that this is a very hypothetical question, but one that we should definitely think about. What if a new UI Framework comes along and the team decides it's time to replace our React codebases with "Library X". Likely by that stage, our entire product suite will be written in React, as well as having a likely bigger React Component Library. Will we be in a good position to refactor everything?

In closing, if WC isn't currently the answer, I still think we should keep our eyes on WC and keep our options open.

Effort Required (estimate based on 1 developer):
Three Quarters

Library Improvements

After conducting research on other Component Libraries, I can't help but think that we might have been too critical of our own library. Of course there are things that we can improve on, but when comparing with other libraries I feel that we are doing a lot of good things.

We have quite a well established component library at this point with numerous components, with all of these being used across a multitude of packages. We have only really encountered the odd bug when consuming the library inside Fusion, but that comes with the territory. A component library evolves with the teams needs and requirements.

What I would say is that the issue isn't really with the Component Library itself, but more to do with the process of how we consume the library inside Fusion. The current process is both time consuming and fragile, fragile in the sense of there being room for error.

Our current process is:

  1. Go to the ui-react-components repository and create a new feature branch from sit
  2. Complete our feature work and create a pull request to merge the work into sit
  3. Wait for two reviewers to test our code, approve the pull request then merge into sit
  4. Now create a new pull request from sit to master, and again wait for two reviewers to rest the sit branch, approve the pull request then merge into sit
  5. Now that the code has been merged to master, create a new release for the ui-react-components package
  6. Now change repository to ui-fusion, update the ui-react-components package version
  7. ... and now pray that the updated version works for the main feature work you are currently working on, and hope that it does not break anything else

That is a lot of steps to take to simply update a component. The way that we can drastically shorten this process is to add the library to our Fusion codebase.

This process would then look something like this:

  1. Go to the ui-fusion repository and create a new feature branch from sit
  2. Complete our feature work and create a pull request to merge the work into sit

So, how do we do this?

Regardless if we choose to go down the submodule route or adding the package to the ui-fusion git repository, we need to alter the current ui-react-components package to work alongside ui-fusion

Ideally, when a developer makes a change to a component inside the component library, our local Fusion should watch for these changes and reload our local environment. This means we need to adjust the library to add a new watch script that works alongside our Fusion development build, which would consume a development version of the component library. Doing it this way would mean not having to wait for a production version of the library to be built each time a change is made during local development.

To summarize:

  • A watch script will need to be created that works alongside our Fusion build. The watch script should target a development version of the library, so as developers do not need to wait for the library to complete a production build for each small change
  • When the feature the developer is working on gets to a code review level, the build script should be adjusted to build a production version of the library
  • More research may have to be conducted to see the best method of sharing the component library with other teams. We could still potentially perform releases of the component library to NPM for other teams to consume.
Effort Required (estimate based on 1 developer):
One Quarter

CSS Variables

CSS Variables, in my opinion, would be a great way to help simplify the process of making sure our React applications look the same style wise as our Angular applications. But what else can CSS Variables offer?

Well, CSS Variable are easy to manipulate via JavaScript. This means that we could offer easier theming and white labelling capabilities, all with native functionality! That reason alone makes CSS Variables an option I think Team Obsidian should explore.

Effort Required (estimate based on 1 developer):
Two / Three Sprints, depending on scope

Storybook

Making changes to our documentation site for our Component Library makes sense in two regards:

  • To reduce the manual overhead of our current documentation site
  • To revamp our library to serve as a public facing entity so as to improve brand recognition

Storybook has established itself as the industry standard package for providing documentation for Component Libraries. It's setup is relatively straightforward and is easily extendable to serve our brand guidelines. It would also lead to less overhead for the team in order to maintain since routing and other features are handled by Storybook as standard.

Effort Required (estimate based on 1 developer):
One Quarter