search

liqula / react-hs

A GHCJS binding to React based on the Flux design. The flux design pushes state and complicated logic out of the view, allowing the rendering functions and event handlers to be pure Haskell functions.
32 stars 10 forks source link

Find better module namespace. #1

Open fisx opened 7 years ago

fisx commented 7 years ago

React.Flux.* looks like there is a hierarchy on which React and Flux are parent and child. use ReactFlux.* instead?

EDIT / conclusion of the discussion: we leave the module hierarchy untouched (it would still work after a split-up into packages react and flux, and still after other people introduced flux drop-in replacements); the package name is react-flux-hs. anybody who wants to work on separate packages is invited to open a new issue and discuss design.

tysonzero commented 7 years ago

I guess now it can just be React.*, that is what I would guess the namespace to be if I installed a library called react-hs. Perhaps we could even just name the library itself react, doesn't seem to exist on hackage yet.

fisx commented 7 years ago

yes, react would have been a good choice, but not much better than react-hs IMO, and i don't want to spend effort on renaming.

React.* occurred to me, but that would not cover the flux part, which is incidental to react, and definitely part of this library.

So I think I still prefer ReactFlux.

tysonzero commented 7 years ago

But the library isn't called "react-flux" anymore... At least consider ReactHS or ReactHs.

fisx commented 7 years ago

you have a point there. i'll consider React then. that also means we don't commit to following any state handling paradigm.

anyway, not on the top of the list right now. (-:

tysonzero commented 7 years ago

Hopefully we can eventually get this merged back into the original react-flux, then I would fully support ReactFlux.*.

tomsmalley commented 7 years ago

I agree with ReactFlux. I think that flux needs to be caught somewhere in the name since it isn't just a React wrapper. Perhaps rename the library to react-flux-hs or similar to mirror this, in the case John Lenz has disappeared. Has anyone been able to get in touch with him?

fisx commented 7 years ago

i was feeling lazy about renaming the packages, but perhaps we should do that.

i'm not optimistic about john lenz coming back, i haven't managed to get a response via email or bitbucket, and i sure have tried. and even if he does, i'm not sure i want to rely on him staying around.

tysonzero commented 7 years ago

If we do get ahold of him we could always ask him to give the contributors here commit access to the original repository (and maybe migrate it to GitHub), that way even if he disappears again it won't cause problems.

We could even just ask him to let us put this one in its place on hackage and stackage, not sure how that works with versioning. We may have to change our version here to like 2.0.* or something like that.

tysonzero commented 7 years ago

And if we do want to keep the flux (which I do think is reasonable), then yeah we probably should put it in the package name. I think react-flux-hs for the package name and ReactFlux.* for the module namespace is fine, no need for ReactFluxHs.* or anything like that.

tysonzero commented 7 years ago

After some more thought I think it might be worth it to keep react-hs and use React.* instead. It seems like this sort of is the go-to react wrapper, and would like to support multiple state architectures, such as just stateful views (mkStatefulView). I personally would love to work on looking at and improving how stateful views work.

NicoleRauch commented 7 years ago

I think this library is about React and about a Flux implementation, so I would prefer if the name reflected that. My vote would therefore go towards react-flux-hs and ReactFlux.*. I think ReactFluxHs.* is a bit too heavy, also once you are in the code it should be fairly obvious that it's Haskell code ;-)

tysonzero commented 7 years ago

I guess as long as the flux paradigm is privileged above others then ReactFlux is reasonable. IMO it would be nice if there was a good react library that was state handling paradigm agnostic, so I was hoping to make this one that library.

It seems like it shouldn't be impossible to decouple the react part from the flux part. Which would allow us to have a react library and a react-flux library that depends on it. Or if that is too much then at least having the flux part be in a Flux module. I do see the merits of Flux but it has its tradeoffs, and many would like to have the choice.

Now of course if you maintainers decide you like Flux above all else I can't stop you from committing to it, and admittedly right now I don't have the time to make a state paradigm agnostic react fork of my own, but I just think it is something you should consider. I have some thoughts on the steps needed to make it state paradigm agnostic, but I will wait until I have a definitive answer as to the direction the library is taking before I write them out.

fisx commented 7 years ago

I'm ok with somebody splitting up react and flux into separate packages, but I won't do it myself.

It may still be a good idea to open a new issue and write down your thoughts, perhaps somebody else wants to do it and can save some time picking things up where you've left them.

fisx commented 7 years ago

[updated the issue description]

fisx commented 7 years ago

[thanks for all the feedback!]

fisx commented 7 years ago

related: #22.