Description
This issue replaces dhis2/ui#218. The original topic was about how we want to handle context within our UI libraries, but it turns out there's a more fundamental topic that we need to talk about, which is most likely going to solve the context issue:
Organization of our packages inside this repository
We've successfully transitioned to the mono-repo, now is the time we can talk about what we want to do with it.
Viktor already pointed out his vision of the base package in a comment down below:
- Base components are simple to re-use across higher-level components.
- They forward refs &
displayName - Incoming, unhandled, prop are spread onto the underlying root element
- They lack of attached behavior, so they stay pure & deterministic
If we go for this, then I think the ideal structure I'd like to aim for is to have dedicated, small packages for specific tasks,
like validation, layout, input (basically form components), react-final-form (what is forms now), etc. Then there'd be a clear separation between the different packages. All of them (except base) could have translations, make api calls or work on dhis2 specific data structures as long as we expose the base components as well & use names that indicate differences between similar components (e. g. we use Field to show the difference between an input component and an input component with meta data & helpers attached to it; or adding a FF suffix to components made ready for working with react final form)
Alternatives
Alternatively to the approach above is a more pragmatic approach. The current approach has a lot of theory, assumptions and expectations behind it.
For example: We don't know if
- people will ever create their own components using base components
- there is a practical gain from not putting translations on the base components if they can be turned off
I can see the idea behind managing components in different packages, but without having any data backing up our decisions, it's hard for me to see a real benefit and we keep speculating about what's the best approach. We have to rely on assumptions (some are probably very accurate while others might be off by quite a big margin), which feels like a premature optimization for issues that might not even be there.
We've just transitioned to the mono-repo, so we should probably just stick to it and see how it turns out. But what I would really like to do is to collect information. I don't know if there are any tools for this though. Is there a way to see how much time we spend on adding features, refactoring code/architecture or fixing bugs? Is there a good way for us to find out how/where our components are being used?