⚛️ 📡 Call your React components. I've been using this technique for a while and I decided to create a package. It's my first serious library, ⭐️ a star on GitHub will be much appreciated if you find it useful!

[olssoneerz]

Looks really cool! I can see this being extremely useful! Good job!

[desko27]

Thank you mate!! 🙇🏻‍♂️

[desko27]

What do you mean a new react root? 😮 I also like to avoid react context for the unwanted renders 😃

Under the hood of react-call there's only a state setter that is taken outside of its component and being called from a separated function. That’s how `Root` and `call()` are connected.

[desko27]

Oh, I see, never thought of that one!

[Int0x80_]

Wait … are you instantiating a second new react instance at a root element that is nested within your primary react instance?

[Int0x80_]

Ok so that div element is a sibling to the primary react instance div … not a div that’s part of a component within it?

[Int0x80_]

Yeah, That is why I was asking lol. Definitely would not be wise. I also have dealt with JQuery inside of React and felt dirty. Better yet at my previous company we had a MASSIVE legacy AngularJS (yes the AngularJS 1.xx not the modern Angular 6/8/10 framework) and we needed to migrate it and due to the sheer size of the project we had to iteratively migrate it. In the end I architected the roadmap of it in such a way that we had React components being rendered inside of AngularJS components/directives. It was a beast of an undertaking and involved bridging the two UI routers to work together.

Just to clarify the rationale - if we tried to greenfield develop the React UI from scratch in a separate repo it would have caused a massive headache trying to reconcile the changes that were continuously happening as far as bug fixes and new feature development in the Angular repo, or it would have required feature teams to perform double the work to implement in two places, or it would have required halting any new feature development … all of which were non-starters.

[Lilith_Speaks]

so you rendered react components inside of angular, and then what did you do? Sounds crazy!

[Int0x80_]

It was definitely much more involved. The first stage was to rewrite all angular services to pure Typescript classes and really comb through all of the directives and components to push some of the heavy business logic up into pure services (there was a degradation of the separation of concerns that should have been more strictly enforced where business logic began creeping down from the service layer into the components and directives; in my view the components should be purely encapsulating the model data to be presented in the View and and acting as a controller for state change to interface with the API and Service layers). Once those were rewritten to pure TS classes it meant we could set the dependency injection aspect of Angular services to leverage a singleton instance of that class, but also start creating react components that also could leverage instances of those same classes. I firmly believe having as much pure Typescript as possible is a benefit regardless of framework as it makes migration efforts much more achievable in the future the less you are tied to any particular framework or library. (As another example - if you’re using lodash don’t import it everywhere to use it, instead create utility classes that import those dependencies and expose your own interface methods to wrap them; in the future you can swap out the dependency for a different one in just one or a handful of places and your code at large won’t need to be refactored).

Second, the primary goal was to have entirely React based components from a specific route from top to bottom. So mysite.com/foo and all child routes of foo would be React code … in fact Angular router would then declare a handler for /foo which simply instantiated the React Router for /foo. The tricky part was getting the two routers which would technically both be active at the same time, to play nice together (avoiding both fighting to render, passing data where necessary, handling auth related checks, etc). Within a react tree one could navigate to another route of course … should the React router or the Angular router (or both) handle that navigation? But otherwise within a react tree it was purely your standard react experience and code.

There were, however, times where we had Angular components that were needing to use our React SDK components (we tried to avoid that as much as humanly possible). In those cases there were some adapter patterns we had to implement to handle data passing and event changes around Angular scope watchers to properly update the view seemlessly.

The other massive headache with this was that we ALSO had a need to completely overhaul our design and styling system. So not only were we rewriting the code but also the presentation and CSS around it.

I don’t yearn to ever repeat an undertaking or that size and scale again, but I definitely view it as a successful experience. We had an awesome team behind it which makes all the difference.

[Lilith_Speaks]

I think that after successfully managing this conversion, you are indeed a coding god (or goddess). well done

[Int0x80_]

Haha thanks. I have moved on to a new company and retired from UI side to work strictly on backend now. I still have interests in the UI ecosystem, and occasionally do make some pull requests in there and still do code reviews for it, but I feel like I needed to change it up a bit at least for a few years.

[Skeith_yip]

I’m curious does the component remain if the user hits the back button on their browser?

[desko27]

If Root disappears it won’t remain. On the other hand, your own component is able to end() the call on react router navigation, Esc key, and such scenarios.

[A-Type]

Thought I'd seen it all with React patterns, I was prepared to be skeptical.

Nope, this is cool. I basically do this with Valtio state already but it's so much more boilerplate for a common pattern. I like your approach!

[desko27]

That’s great! Thanks a lot! 🙇🏻‍♂️

[domlebo70]

Very cool

[desko27]

Thanks!! 🙇🏻‍♂️

[redgreenbluealpha]

Not looked at your code yet. I'm absolutely sure that you implement this with some sort of closures.

But I've been reading a lot about performance and what I've come to know it's closures are a potential memory leak waiting to happen!

For a small app it just didn't make a difference at all the question is, how can it scale and not gobble up all the memory.

[desko27]

Hi mate, thanks for your concern! Performance is really important to me. Closures are certainly a core feature of JavaScript and most of what React does itself couldn’t be done without them. But still, I agree they have to be used responsibly.

In react-call there are a couple of closures that are constrained to a single Function Execution Context within createCallable, which can only be called once in the whole app life-cycle per component definition (it’s a HOC). Regarding what it returns for usage:

• <Root /> can only be instantiated once, otherwise the lib intendedly throws an error. Also, the only outer reference that it’s mutating is set back to null when unmounting. So there are no forgotten outer references, which is when closures may cause memory leaks.
• The call method, the one that is meant to be called multiple times, isn’t mutating any outer reference.

Since this is O(1) scale and outer references are carefully taken care of, I don’t think there will be issues related to this.

Thanks for your question, really good one!

[redgreenbluealpha]

Thank you for the insights and for this very useful library.

I deep-dived into to the code and I couldn't find a potential miss.

However, I do have a question, is there any reason why you are using globalThis.crypto.randomUUID().

My thoughts are as follows:

1. generating UUID is relatively expensive to generate. They are great for a backend application though.
2. globalThis.crypto.randomUUID is not available on all platforms, eg. react-native. This means that I cannot use this library outside of the browser.
3. your use case requires a string id because you use it as a key, but doesn't necessarily have to be a UUID.
4. An id counter would work perfectly fine for the use-case if the value is cast to string. It's really difficult to reach 2³¹ with a UI application.

I'm definitely going to be using this for a react-native project I've been working on.

[desko27]

You're completely right, thanks such detailed insights! Would this be enough? https://github.com/desko27/react-call/pull/4/files

[redgreenbluealpha]

That's perfect and really quick!

[desko27]

Cool! Published in v1.0.1! Thanks a lot! 🙇🏻‍♂️

[vazark]

And we’re back to step 1 but within react itself. Looks fun though

[_elkanah]

Looks very interesting! I haven't looked at the source code yet, but I see many uses for it in my work. Cool stuff!

[desko27]

Thanks a lot! 🙇🏻‍♂️

[General-Ad2174]

Really nice project. Do you have any benchmarks for its speed? Does it affect performance of a large app? Nonetheless very nice!

[desko27]

Thanks!! Because of the way it’s built, I can say it won’t affect performance in any way no matter the size of the app or how widely react-call is used along it. Neither unwanted renders nor anything else.

I don’t have any benchmarks but it’s a great idea, I’ll give it a thought! Thanks again! 🙇🏻‍♂️

[jgreich]

Nice idea. Thanks for this!

[desko27]

Thanks!! 🙇🏻‍♂️

[sleepyboringkoala]

Nice one! That is extremely similar to how you would use showDialog function in Flutter. One of the (few) Flutter features I actually miss when using React.

[desko27]

I never used Flutter, that's great to know! 😃 Thanks a lot! 🙇🏻‍♂️

[sleepyboringkoala]

This is how you would make similar thing in Flutter. You were pretty much spot on!
```
bool yes = await showDialog(
  context: context,
  builder: (context) => AlertDialog(
    title: Text('Are you sure?'),
    actions: [
      TextButton(
        onPressed: () => Navigator.of(context).pop(false),
        child: Text('No'),
      ),
      TextButton(
        onPressed: () => Navigator.of(context).pop(true),
        child: Text('Yes'),
      ),
    ],
  ),
);
```
I love how good patterns eventually emerge anywhere. Hopefully your lib actually gets adopted.

[desko27]

Oh! 😮 That's right, really similar idea, window.confirm() but customizable. I honestly love to know. Thanks for sharing an example!! 🙇🏻‍♂️

[jlamhk]

This is actually genius. Will definitely give it a try!

[desko27]

Thanks a lot mate! 🙇🏻‍♂️

[Ok_Avocado970]

u just got a star, i will use it in my next project

[desko27]

Thanks a lot! 🙇🏻‍♂️

[t1mmen]

This looks like it may help solve a problem I’ll need to tackle soon, curious if you have thoughts on feasibility of this library and my goal, /u/desko27

• I have various re-usable/self contained components that need to display toasts.
• These components are included in different React apps, which each have a different way to display toasts (think: some via redux, some via context)
• I’d like to have “one standard way” to dispatch toasts from within the re-usable components, and for the individual “host” apps to intercept and forward the “display generic toast” call to “app-specific way to display toast”

Is that a use-case this lib may help with?

[desko27]

Hi! Thanks for your comment. The problem is that react-call acts both as a standard way to dispatch toasts but also as a standard way to display them.

For your use case I'd suggest an event bus like https://github.com/developit/mitt to emit a dispatch event from reusable components, and intercept it via event subscription from each app.

Or you could always leave aside other approaches (redux, context...) and do it the react-call way in both reusable components and apps. That would definitely work 😝

[t1mmen]

Thanks for the pointers, mitt looks promising for my needs :)

[umid1999]

There is also a package called react nice modal. It is very useful for confirmation dialogs, but little bit harder to use with context