I would be interested how to move away from react. Either you write a lot of wrappers and not using the react-* libs at all and put in extra effor all way long, or it is quite hard, isn't it?
If you are generally interested in how to write components that can be used by many frontend libraries (react/vue, etc), you should take a look at https://github.com/microsoft/fast. I was tangentially involved with porting an existing component library to it and the end result was pretty framework agnostic and well made.
You need to become familiar with ShadowDOM if you are not already.
I am hopefully many years away from any such effort :)
But there are still things one can to do prepare, such as:
- cleanly separate as much of your state logic as possible into something like redux which isn't tied to react and can be used in many alternatives (svelte, solid, etc), which _increases_ but does not _guarantee_ that that logic will be reusable.
- choose ui component libraries that have implementations on top of multiple libraries. Many react apps today are built using mui, and there are similar (though less powerful) implementations of the underlying design system (material _design_, as opposed to material _ui_) for other frameworks. This at least cuts down on design work/decisions. If your webapp is going to (presumably easily) look the same before/after, you don't have to have a ton of design meetings to decide how different is too different. Notably this is the reason why I wanted to move from react-vis to echarts at my job: it was possible to transition with very little visual difference.
- Separate your data fetching logic out of react components. Implement a library for fetching data for your api, then implement a set of very light hooks/wrappers around that library, and then use those hooks/wrappers in your components. (note: this suggestion may be indistinguishable from 1) if fetching is very tightly tied to your store).
That may seem like a lot to do, but I think 1/3 at least are good ideas even if you plan on being on react for _forever_.
Most of what I wrote is based on preparing something like an SPA, and I'd imagine the considerations are very different from something that uses SSR. I'm personally not a fan of SSR, or at least the space I want to work in doesn't see any benefits from SSR, so that's not something I think about.
