Other renderers than React

[dmitriid]

It's not a fully fleshed out idea with just a vague description so bear with me :)

I wonder if it's possible to extend/change rum to allow other libs (not just react). I was thinking primarily snabbdom but possibly also Preact or other react-like and virtual-dom libs

It looks like this may be possible with (slight?) modifications to build-defc and extracting react-related functionality to a separate namespace (e.g. rum.react).

Obviously mixins defined for react wouldn't work with non-react components, but this could be handled by thin converter wrappers if necessary (most frameworks provide similar lifecycle methods anyway).

What say ye? :)

[martinklepsch]

@dmitriid Besides the build-defc changes you mention this would also require an implementation of Sablono for the DOM library you wish to use. That's probably the bigger issue compared to the changes in Rum.

[dmitriid]

Oh, right. That completely skipped my mind. Argh!! :)

[tonsky]

People keep asking me about this from time to time. Frankly, I never understood, what do you hope to get from this? How would it benefit you? What other renderers can do that React can’t?

[dmitriid]

Anything from resulting bundle size (snabbdom is tiny) to better rendering times :)

I'm quite happy with rum as it is right now, it was just a thought (as I played with snabbdom previously as well)

[ku1ik]

@tonsky I think most people want to get the resulting file size down, and so do I. There's reagent issue where they report to shave off 113kb of resulting file size (non-gzipped) by using Preact: reagent-project/reagent#271 (comment)

I agree it doesn't matter much if you build single .js file for your web app and you gzip it, but there are use cases where you distribute build artifact and then people constantly ask you why does it have several hundred kilobytes and don't want to use it because of that.

Performance may be another reason for some I guess.

[DjebbZ]

The thread that you @sickill linked in Reagent has a very good argument against doing this for Reagent, and this applies for rum too. The TLDR : it's too early to know exactly what abstractions should be built to allow transparent and conflict-free swapping of renderers. Friendly forks for the sake of experimenting are the best bet now.

[mseddon]

People keep asking me about this from time to time. Frankly, I never understood, what do you hope to get from this? How would it benefit you? What other renderers can do that React can’t?

The reason this would benefit me, is that ReactJS events are broken under Chrome and have been for well over a year, now: facebook/react#9809. So I would say "other renderers can do... DOM event handling correctly." ;)

TLDR: Because ReactJS attaches all events on document, and Chrome forces any events on document to be passive by default, all events are now passive in React under Chrome. Because they still haven't applied a one line patch that binds the addEventListener with { passive: false }, it is physically impossible to call preventDefault from within a React event handler under Chrome, and as you can see from that issue, Facebook are shrugging and saying "Chrome broke us, not our problem".

The workaround is to bind your events within onComponentDidMount, and of course then remove them in the onComponentDidUnmount handler - which is not pleasant to use, even within Rum.

That being said I do also agree with the the argument @DjebbZ pushes forward in the general case, but when I swap out the 'default, supported' back-end for an 'unsupported, maybe works' backend, I am happy to accept the risk myself. This could be achieved without breakage by having a rum-core artifact, which assumes the presence of any react implementation that is required to be compatible insofar as Rum uses it, and a rum artifact that includes both rum-core and the relevant 'official' ReactJS implementation. Given the modest size of the rum codebase, I can trivially PR upstream to Preact or Inferno etc. anything that is needed to keep my code running.

Anyway, that is my two cents. Unfortunately since most ClojureScript React libraries are tied directly to ReactJS's implementation, and I write fairly hairy complex components that do, as a matter of course, need to call preventDefault, I cannot use them directly in my day to day, which is a shame.

[tonsky]

Thanks for the explanation @mseddon! I got bit myself by this problem. I don’t mind alternative backends, will look what could be done about it in the future

[piranha]

Sablono is tied to React, so it seems a new template engine will be necessary here...

[mseddon]

Just had a look at the sablono source, and it is using js/React to access the api, but has no hard dependency. It should be possible to arrange for a different engine to be placed there as is. That said it may be worth chasing upstream and seeing if a cleaner approach would make more sense.

[roman01la]

We are not gonna do that, Preact is different enough from React such that it can introduce more complexity into the codebase.