Maturing some components/logic out of labs into react-components

[goneale]

Hello, @bertearazvan and fellow Board of Maintainers

We have recently updated our ScenarioList component to commence using the Mike Color Theme and ThemeProvider you have provided in Labs, due to Design Guidelines for newer projects.

Unfortunately as we've been having to move quick and don't see any easy other way, this has basically resulted in a copy of the ThemeProvider folder and mikeColors which is of course not ideal.

@FranzThomsen1089 and I feel this could be a great time to discuss maturing some of this functionality from labs into RC-TS official?

1. How could we go about this
2. What would the structure look like
3. Are you comfortable with starting with ThemeProvider and Theme related infrastructure?
4. Are there any other components you feel could be ready?

Please share your thoughts
Many thanks

[bertearazvan]

Hello everyone,

I am very pleased to see that there is interest in moving the components to a more mature library, and I am excited to take it there. I think we need to discuss a few considerations we have been having in the past months.

• One of the objectives is to go over the "board of maintainers" and see who is active, who contributed, and who do we consider to be a maintainer here. So far, I noticed that not everyone has contributed to the lab library - but many thanks to @rihr @rosudhi and you guys from AUS who maintain the main react-components library. 👏🏼 🚀
• The way we(me, @rihr, @j08lue) see the react-components library is that it is tightly coupled with the "domain-services" logic, and we believe it should stay like that while starting fresh with a package called @dhi/react-components-core, where we would have UI components that are generic and can be used by anybody. This way, the components that are generic from the react-components could potentially be moved there.
• We are considering migrating the library to MaterialUI v5. This implies that the package will not really be usable in older projects, but rather be used in new projects from now on. We would of course keep the v4 in the lab concept for a while and will be available in the 1.x.x versions of the react-components-lab.
• Involving @rosudhi's issue a while back Add unit test to components #122, I think we should consider unit testing for when the "components are mature enough" and ready to be moved to the core.

All of the above are questions and suggestions involving everyone that has a say in regards to the library and its future. We also have people onboard from other departments around the world who are willing to build a frontend community and contribute to this project, so stay tuned for a nice frontend community thingy in the near future.

How does this sound?

[bertearazvan]

Unfortunately as we've been having to move quick and don't see any easy other way, this has basically resulted in a copy of the ThemeProvider folder and mikeColors which is of course not ideal.

There should be an easy way, maybe by using yarn workspaces, same as it is here, I think. https://yarnpkg.com/cli/workspace

yarn workspaces creates symlinks in the "node_modules" folder, targeting the workspaces that you have in packages. So maybe if you run yarn workspace @dhi/react-components add @dhi/icons, it should work. When we developed this monorepo we tried to go around the react-components package, so that we don't change the way you work with it. If you want these packages to be integrated together. Oh, wait... the yarn 2 changes are only here #251, and not in the pipeline.

^ I think currently we use lerna on the master branch, which I think has the command lerna bootstrap --force-local. Maybe we will soon make the yarn 2 change, so we don't have the overhead of lerna, but only rely on yarn.

[FranzThomsen1089]

In the react-components its probably around half that assumes Domain Services as backend and if its needed, that can be abstracted away, so I don't think we should focus too much on that as being a show stopper. In all components, but lab and non-lab assumptions has been made other on design of components based on the specific use case that will not apply to other projects, but that should not be seen as a show stopper either.

Creating a react-components-core would IMHO not solve the fundamental problem of merging the two together let alone answer if we should. I am still hoping that there will be some of centralized governance from T&I to help answer these questions and execute the conclusions. My opinion here is biased and of course if we merge things together, I think it should be the react-component that it should be done into as we have no resources here to do any reengineering. I am sure that the same rationale is behind the idea with react-components-core where you would just move things over 1:1

As it is now, the only overlap is in fact that it sits in the same repo. The plan was originally to move component from lab to non lab, MUI style, but I acknowledge that time has passed and lots of things have changed

My suggestion is that we leave things as they for now and let T&I take the initiative for next steps on this topic

[bertearazvan]

Creating a react-components-core would IMHO not solve the fundamental problem of merging the two together let alone answer if we should. I am still hoping that there will be some of centralized governance from T&I to help answer these questions and execute the conclusions. My opinion here is biased and of course if we merge things together, I think it should be the react-component that it should be done into as we have no resources here to do any reengineering. I am sure that the same rationale is behind the idea with react-components-core where you would just move things over 1:1

I agree that there should be some sort of "centralized governance from T&I" that should make a final decision in such regards, but I also strongly believe that these decisions are made based on our suggestions and experience as developers, which is why I am trying to find solutions that make sense for everyone.

It is important that in the end there is one solution where we have components that do not have any backend logic from domain-services or mike or others, but rather to be generic enough so it can be used by everyone around the world. The solution with "react-components-core" came in order to accommodate the fact that the "react-components" is coupled to domain-services.