Consider decoupling Reagent from React

[skrat]

I would like to open a discussion about this. Preact is much simpler, with easier licensing, and way smaller in size, with mostly compatible API.

https://preactjs.com/

As of the ES6 API, it should be possible to leverage Closure Compiler for cross-compiling to ES5.

[Deraen]

Preact doesn't work with React-native.

Lack of stateful components would require changes in Reagent and would break many projects using Reagent.

But maybe it would be possible provide an option to use Preact.

First thing that could be done separate to Reagent, would be to create package for Preact: https://github.com/cljsjs/packages

[Naomarik]

With all the fast, lightweight competing JS frameworks today, what basis would you choose preact over something like mithril, vidom, or inferno? If there's to be a discussion on being able to optionally wrap another framework, should we first discuss a way to evaluate the best alternative?

[developit]

Aside from the React Native point (which is correct and can be a reason to use React itself), the reason one might choose preact is because it maintains nearly perfect API compatibility with React. This is very different from switching to an arbitrary frontend framework, since it does not require any changes to your code.

Stateful components are definitely supported by the way, let me know if there's an article or something out there seeming to imply otherwise. Also preact works fine without ES6 or anything, it supports IE9+. Cheers!

[Deraen]

Preact retains a large amount of compatibility with React, but only the stateless functional components and ES6 Classes interfaces.

I just skipped ES6 classes part as it is not something I'd be usually interested in.

As the API is nearly perfectly compatible it is possible that nothing needs to be changed in Reagent and users could just change the dependency. For this to be possible, someone should finish packaging Preact in Cljsjs: cljsjs/packages#719

[skrat]

With the cljsjs/packages#719 (comment) merged, should we try to do this and see what happens?

[developit]

I'd be excited to see a demo of this if anyone gives it a go. Really neat stuff!

[KeeganMyers]

Just adding my two cents. I started working on a fork previously that used inferno and found converting from react to inferno to be very simple. However, I only used stateless components. Eventually I abandoned the fork due to lack of time and testing utilities for inferno. Of the virtual DOM libraries I have tried React is currently the only one that has its own testing utilities. I think rendering components to hiccup data structures would increase test-ability and allow an easier transition to other JS frameworks.

[developit]

@KeeganMyers preact-jsx-chai is fairly capable for testing, though I'm not sure how these types of things work for ClojureScript. I am working on a way to use Enzyme with Preact, if that's what you were referring to (since React's TestUtilities option is deprecated).

I don't mean to imply that you should consider them equivalent though. Preact is an optimization for web, React is a reference implementation with all the necessary abstractions for multiplatform. I think the compelling thing for Reagent would just be a flag that would let people output preact if their use-case is a good fit for it.

[piecyk]

Is someone working on this ? planing to hack on this over the weekend!

[skrat]

@piecyk I was planning to but having hard time finding time, go ahead.

[developit]

@piecyk hack away! 😍

[piecyk]

After quick look... just included preact, preact-compat, preact-render-to-string we got

Ran 101 tests containing 2286 assertions.
11 failures, 2 errors. 

and demo page is fully working 🎉 out of box, awesome work @developit 👏

I think i will create reagent.impl.provider that will have refs to react / preact or better export functions to don't have refs to it in ohter places just hide it here, i think we don't need all stuff from preact-compat etc...

[danielcompton]

I can fully understand the desire for something like this, but I don't know if I'd like to see it as part of Reagent, at least not initially. Reagent was built around React and has close integration with it. While it would be possible to add another layer of abstraction to let people choose between React and Preact, what will happen if/when React provides features that we want to use but Preact doesn't support? I fear that we would run into a lowest common denominator situation.

An alternative option could be a friendly fork of Reagent (perhaps even within the reagent-project org) which swaps out React for Preact entirely. That project can then have room to breathe, experiment, and find what is the best way to write the code. If in (say) a year, there is continued interest in the project (and Preact is still being maintained(!)) then it could be possible to reintegrate Preagent with Reagent.

That option would also have the advantage of giving you a much faster feedback loop. It's quite likely a change like the one you are discussing will take a while for Dan to approve and review.

With all that being said, it sounds at the moment like this may be a pretty minimal change, so perhaps a separate project isn't necessary?

[skrat]

While it would be possible to add another layer of abstraction

It's not a layer of abstraction, it's a configuration variable + swappable backend for an API that Reagent is using

what will happen if/when React provides features that we want to use but Preact doesn't support

I don't think that's a valid reasoning. I think Reagent is built around using React's API, and if that API is implemented by different library, with different features (size) that users are after, then why not? Taking into account hypothetical future features of React is not a valid argument.

It is a very common pattern to have different backends and I don't see any downsides to it. The usual approach to provide some implementation specific is to expose the backend and let the users do anything they want to do with it.

[piecyk]

@danielcompton you are so true! Also seeing how fiber can change a lot in near future regarding how react internal will work bring more doubts about this... preact on the other hand can win with some web worker integration

It looks like preact did great job and out of box 99% is working the same, just poking with this looks like it will be so small change, IMO we could just provide 3 files with api contracts that will dispatch correct implementation regarding what people want to use

(ns reagent.impl.provider)
(ns reagent.impl.dom-provider)
(ns reagent.impl.dom-server-provider)

[Deraen]

Providing adapter to only render is probably not enough as some things that need to call React happen outside of render loop. If we just have global adapter value and function to change that, it could be possible to implement this without breakage.

[danielcompton]

I'm still of the opinion that abstracting this out in Reagent at this stage is too early. Making it pluggable means that we need to find the right abstraction. This is difficult to do without implementation experience, and once the protocol is created it will be hard to change. I would suggest forking Reagent to use a different rendering backend, then making a PR to merge it back in after you've learnt the implementation lessons and have a good idea of what a good protocol for this would look like.

OTOH I haven't thought too much about what a protocol would look like here, so maybe the protocol would be obvious and simple?

[yogthos]

I think doing a proof of concept fork would be a good idea. I think creating a protocol will result in cleaner code as well, as it would require untangling anything that's React specific from Reagent.

It would be good to work back from the API that Reagent exposes to the user and inform the protocol based on that. The good part is that Ragent API is fairly small, so I don't expect the protocol to be terribly complex, but I could be wrong here. :)

If nothing else, there would be value in the exercise just to figure out what constitutes core functionality in Reagent.

[kraf]

I stumbled upon this today: https://medium.com/@raulk/if-youre-a-startup-you-should-not-use-react-reflecting-on-the-bsd-patents-license-b049d4a67dd2

I think the licensing issue is a huge deal.

[mike-thompson-day8]

And there are contrary opinions on the patent clause which say the fuss is much ado about nothing.
https://medium.com/@dwalsh.sdlr/react-facebook-and-the-revokable-patent-license-why-its-a-paper-25c40c50b562

I'm not a lawyer, so this is hard for me to judge legally but, empirically, React has been out for 3.5 years, and I've not heard of a single startup getting sued.

But if you are sufficiently worried and motivated, I think the previous advice still stands: you should fork Reagent and create a proof of concept based on Preact. I'm fairly sure the current maintainers are not about to change Reagent itself in this regard.

[yogthos]

I agree that this is unlikely to be an issue for most people. However, the fact that Facebook can arbitrarily decide to sue you is a valid concern. The clause is intentionally vague, and Apache Foundation seems to think this is reason enough to black list React from their projects.

I also think there are other advantages aside from the license issue in abstracting the React layer. If somebody is motivated to explore decoupling React, it should be done in a way that's backend agnostic. As @Deraen notes, the team would be open to having a protocol. This would also help isolate what constitutes core functionality of Reagent.

[skrat]

Facebook will sue you when it sees your app (using React) as a threat to their business.

[ggeoffrey]

Facebook just relicensed React to MIT:
https://code.facebook.com/posts/300798627056246/relicensing-react-jest-flow-and-immutable-js/

[yogthos]

I think this allays any fears over the React license. I do think that decoupling from React might be worth exploring though, so I'd keep this open in case somebody wants to look into it.

[tomconnors]

I updated @Deraen's project to use the latest cljs and reagent: https://github.com/tomconnors/problems/tree/reagent-preact. For anyone who just wants a smaller build size, this seems like a pretty good option right now. All that was required to get this simple project to run was to provide the lein :exclusions and the :foreign-libs and :externs options to the compiler. I'd hoped to use the :npm-deps option, but that doesn't appear to work because we need to use the "preact" package to produce the "react" namespaces.

[ashnur]

Maybe https://www.npmjs.com/package/react-reconciler ?

[jleonard-r7]

Is anyone still attempting this?

[ec-c]

What about using the preact/compat alias package? npm install react@npm:@preact/compat react-dom@npm:@preact/compat

[LeaveNhA]

Are we considering this?

What would be our road-map, limitations, etc.?

[Sleepful]

the licensing isn't all there is to Preact, it comes with a good deal of better features than React, such as Signals and a lot less bloat