This question is about possible higher-level approaches that one could take to applying version control to React components. Specifically, these components should be more on the "atomic" end of the spectrum, i.e. doing one thing powerfully in a variety of contexts.
Specifically, I'd like your thoughts on versioning such components at scale, whilst addressing issues such as:
Cross-project usability (i.e. <Button /> component in both of my React apps);
Theming (how themes and styles can be shared across these components); and
Dependencies (e.g. version 1.0.5 of <StackedButton /> depends on version 2.1.0 of <Button />)
I've been looking into Bitsrc.io as a possible tool to help me manage this. I've been largely addressing these issues by having quite a few (~10) Git repositories, each managing a loosely coupled set of components, e.g. text-components, layout-components, table-components, but I feel like I'm at a point, where with the number of components and the dependencies they have, further maintainability may be sacrificed if I make the wrong decision.
I've had some success using lerna; I think it might fit your needs pretty well. You basically would combine all 10 of your repositories in a single one, with each one now being a package within the repository.
Lot of advantages to this approach. Mainly, it lets you still have separate published packages, giving consuming apps flexibility on what they want/don't want to pull in, but it removes a lot of the overhead of having a lot of packages. It becomes much easier to make sweeping changes, and it's impossible for your packages to get out of sync, since they're always updated together. If you make a breaking change in one package that another package relies on, you would fix the package in the same PR as the breaking change.
Related
There is an issue with a bit outdated Nrwl/NX project which configuration was not updated to latest.
Too many libraries are being affected via Nrwl/Angular app.
Dependency graph clearly shows double-sided arrows pointing back AND forth to Nrwl/Angular app, meaning this parent app(Nrwl/Angular) changes for some reason affects libraries which are only children and shouldn't be touched.
Due to this issue too often majority of libraries are built/linted/tested.
Newly empty created Nrxl/NX project does not have such issue and children are connected ONLY downside with single-sided arrows.
I cannot find what is the main cause for current project.
Would appreciate suggestions/guesses where I should focus or how to approach it in finding the reason WHY parent app changes affect children libraries.
P.S.
Using #nrwl/angular": "12.10.1",
The cause of this behavior was incorrect design/usage of NX project.
After migrating to NX, up to this point we had moved about 60%-70% of components to libraries, but we had mixed imports between libraries and the remaining not migrated Angular app shared components.
Just by editing single tiny library, which had some-angular-app-component imported and vice versa, that same library being used in some-angular-app-component - The outcome was chain reaction of lots of such import connections, which marked as affected 90%-95% of the NX project.
Always make sure dep-graph shows waterfall connections to avoid such issues and follow NX design recommendations.
There is a medium-sized application written in Vue 2.7 (vuex, vue-router, etc.).
Until a certain point, we had SSR "with our own hands." Works crookedly and slowly, but works.
Recently, it has ceased to satisfy the needs of the project and we realized that we would be migrating to Nuxt.
Relatively recently, Nuxt 3 was released. It is now in rc state. We are betting on the further development of Nuxt. Therefore, we want to migrate to version 3. In addition, I think that in the near future we will consider switching to TypeScript, and in Nuxt 3 TS support is at a good level.
But there is an ambiguity: Nuxt 3 works with Vue 3. Also, it is recommended to use pinia instead of Vuex.
In this regard, questions:
Will most components work on Vue 2 when using Nuxt 3? I also want to move to Vue 3, but for now we want to speed up the process as much as possible. But I don't want to use crutches like "Vue 3 Migration Build" either.
Is Pinia definitively replacing Vuex? I mean, is Vuex going to be obsolete anytime soon?
Maybe there are more pitfalls that you should know BEFORE moving?
I would first off migration from Vue2 to Nuxt2, for the simplest + fastest approach without too many breaking parts. That way, you can at least benefit of some SSR capabilities until your whole migration is done.
Then, as Estus Flask said, the main issue would be the packages themselves (like Vuetify, which are still not fully Vue3 compatible in a stable state).
Also, you can totally migrate to Nuxt3 while keeping most of your components with the Options API (no need to refacto towards Composition API).
Nuxt3 is runnable in production but you may still need to troubleshoot it depending on what you are planning to use. Also, keep in mind that not all the modules are migrated yet, here is the latest roadmap.
So to answer your questions:
depending on how your components are now, you may need to update some of their parts, for further details you can check the migration guide and see if you are anyhow impacted by the changes when going from Vue2 to Vue3. If you want to iterate faster (and in a safer way), migrate to Nuxt2 first (should be quite fast!), then try to move towards Nuxt3
Pinia is better on pretty much all aspects when compared to Vuex. Will it be un-usable in the next 18 months? Probably not. It's still the official recommendation and will be the way to go overall (it's just better overall) but Vuex is still totally usable as of today. More details can be found here
as always, you gonna add a layer on top of Vue so it may impact several things:
depending on the amount of features you are using (Nuxt modules, Nuxt specific modules), some releases may take a bit more time overall to ship to production (using Tailwind with Vue3 was made possible earlier in comparison of Nuxt3)
Nuxt is a meta-framework, so it will bring some amount of complexity to properly understand all the Nuxt2 hooks, the way an isomorphic app works, how to use Vue2 packages, some gotchas etc... This is not coming from Nuxt itself, but more from the SSR part.
Nuxt3 is using Vue3, so you will need to then understand a bit more
how composition API works to get the benefit of using useAsyncData
composables etc... So the same work will be needed there too, hence why
I recommend a transition to Nuxt2 first. Of course, it all depends of
your team and if your members are already at ease with Composition
API
Overall, if you need a production-grade solution for your SSR needs, it will be quite useful to use Nuxt for sure but it will also require a bit of a learning curve.
You will also get quite some DX out of it, so that's a nice bonus!
Also, there is no real competition to Nuxt in Vue's ecosystem so at least, you don't need to fully compare meta-frameworks. AstroJS could be another approach but it goes out from the Vue ecosystem quite a lot overall (you won't benefit of Nuxt's modules/nice features for example) and solves some specific needs.
PS: Nuxt's team is working on the same approach regarding server-only components + heavy improvements regarding the hydration.
In team Vue.js project I'm curently working, I wrote something like this in view:
component01
component02
...
There is more than 10 componenets. In every component is one section of landing page, nothing fancy, mostly HTML/CSS and some animations, components don't have props and are used only once. Idea is to simplify maintenance of code - instead of editing view page with, for example, 1000 lines of code, we can edit component with 100 lines of code.
And got instructions to merge all components into one view (eg. 1000 or more lines of code). I'm OK with that, but got me thinking and searching for opinions.
Is there best practice for situations like this - use components even if there is no repeating and no props, to simplify code, or hold everything in one view (and long) file. Components can be in separate folders, so big number of components should not be a problem. Or will they?
Components are the building blocks of all modern JavaScript frameworks as they provide a better overall architecture for your application in terms of reusability, testability, maintainability and in the end SOLID and KISS principles.
I would recommend splitting your app in smaller and presentational components and use services for business logic. It does not matter if the application is small, by following these principles it will be able to grow with no or less pain. That is the way Angular encourages you to build applications.
As always in this industry, don't overuse these concepts and apply where appropriate and with common sense ;-)
I'm sure this is a bad idea for technical reasons but haven't found any source explaining if it is or why.
Let's say I'm building a React website and want to use two component frameworks, like ant.design and material-ui because I love 90% of what ant.design does but I just slightly prefer the modal dialogues in material-ui more and want to use those in conjunction with ant.design components.
They both seem to play quite nicely with each other.
Why is this a bad idea? Is there potential for conflict in future? Does this increase bloat somehow?
You may want to refer to this question asked yesterday for a little pointer:
How to make Bootstrap 3 and Ant Design 3 live together
As pointed out above:
Bloat - the unnecessary inclusion of code you do not need, which can be avoided through custom builds.
Duplication/Overwrite - code included by duplicate existing or merely serve to overwrite existing rules making the code 50% pointless.
Conflict - issues may arise from conflicting JS code, not least from the potential to have conflicting version dependencies.
Namespacing - as identified in the linked question, it is impossible to namespace the antd css to avoid collision with bootstrap.
Code Styles - No two libraries will be implemented in exactly the same way and you will find yourself having to navigate issues that arise from this.
In my own experience I have never found a single library/suite that delivers everything, but the closest I have found to this is Ant Design.
Visually it may not be the best, and there may be implementation/pattern issues that some developers do not like, but the reality is that the less you have to build, the quicker you can deliver, and end users will care more for functionality than they will the way your app looks. The priorities you place on these things will differ from them for sure.
I personally love the look of Material UI and others, as highlighted here:
https://hackernoon.com/23-best-react-ui-component-libraries-and-frameworks-250a81b2ac42
But the reality is, you need to look to which single framework and set of components provides the best and most complete functionality you actually require.
In my case, as mentioned, this was Ant Design; being the only one with a strong set of UI components including Date Pickers etc, without having to add more and more components into my codebase via NPM.
I read articles criticizing React for setState being weird when instead the people criticizing it did not understand it properly.
I really like React modularity, and the more I learn it the more I find it intuitive.
Nevertheless, I ran into multiple situations in which I would have liked the states to be cross-component. What I mean is, changing a state in a component could affect another component. It is my understanding that there is no React built in solution to this problem. Of course there are ways around it but there is no fixed protocol.
My question is, why is that? what is the advantage of not providing a simple way to handle such a common scenario? Or if there is and I don't know about it, please enlighten me!
There are at least 4 out-of-the-box ways to share state between closely related (and unrelated) components: props, callbacks, refs, the ctx variable.
I simply think it's built to be as small as possible with the complete intention that if you need an app state manager for a complex project (where unrelated components need to communicate) that you will include one, and they will not force you into any one approach.
If you did want something with more substantial scaffolding to start a project, which many people do, you could refer to react-boilerplate or similar.
But having React itself limited to the minimal, I have the freedom to choose (or not) the best tool for each project without having to override one-size-fits-all defaults.