Decouple react flux

[tysonzero]

Starting the decoupling process. I will make all changes on the decouple-react-flux branch so that we can discuss and test them as we go, without affecting master at all.

@fisx I would love some input on the general idea and any feedback on the changes so far (nothing too huge yet, just moving some stuff around a bit).

[fisx]

oops, missed my deadline on this one. it's ok that you merged, we are currently not using this any more, so any direction you take this in has a good chance of being an improvement. (-:

only one remark: the kind restriction of eventHandler was intentional i don't remember the details, only that it was both awkward to use and had a good reason. i don't think it's been added for all that long, you may find something in the history. or you may choose to keep it * and hope for the best.

[tysonzero]

@fisx You aren't using react-hs at all any more? What are you using instead? Also it's not merged into master, its into a different branch so I figured it was fine to just merge it.

And keeping it *, while unfortunately less constrained, is the most practical way for me to achieve what I want, which is being able to create views with absolutely any event handler type (flux-based or IO or some other state handler).

[fisx]

What are you using instead?

sadly, we may be switching back to good-old react.js plus flow. it's got its deficiencies, but i must say we under-estimated the issues with getting ghcjs to work in general, and we grocely over-estimated the production-readiness of react-flux.

* [...]

ok, fair enough. just saying. (-:

[tysonzero]

That's unfortunate to hear, I hope you are still interested in maintaining react-hs, at least on the more high-level side, I can probably do quite a lot of the needed coding. It might be worth reaching out for contributors.

It seems like reflex-platform is actually a pretty good way to build GHCJS apps, even ones completely unrelated to reflex (name change probably on its way to highlight that fact), so it might be worth it for you guys to look into that before dropping react-hs completely. There is one outstanding issue remaining (missing ghcjs-base typeclass instance in the forked and optimized ghcjs-base used), but once that is fixed I think it should work nicely.

[fisx]

that's still a lot of "if"s and "once"s for production use...

i know reflrex-platform, but it does not help with

• the slow build cycles
• when (not "if") you need to run on a more recent ghcjs commit (that you sometimes have to write yourself)
• the (at least) 3 conflicting and undocumented mental models that are by now the basis of react-hs.

so yes, currently i am not very optimistic. still trying to decide how this should affect our react-hs maintainership. (should the warning in the README be more explicit? feel free to change it.)

[tysonzero]

I looked into miso and it seems like it allows for very nice react-style Haskell front-end development. So I honestly might switch over to that (and I'd suggest you take a look at it too), and then I guess we could suggest in the README that others do the same.

I realize it's a pretty drastic measure but I'm realizing that maintaining react-hs will be a significant undertaking, particularly considering all the changes I'd like to make. It seems as though miso should check off all the main things we have discussed, such as the modularity / local state stuff I want (via the View functor instance), and the constrained (you can enforce no IO) event handlers you want plus it seems like you can implement flux architecture without too much difficulty.

I will of course try out miso before doing anything further. But I'm curious as to your thoughts on this approach.