Skip to content
This repository has been archived by the owner on Dec 30, 2018. It is now read-only.

switch to a much more vanilla flux solution #28

Open
vesparny opened this issue Feb 3, 2015 · 15 comments
Open

switch to a much more vanilla flux solution #28

vesparny opened this issue Feb 3, 2015 · 15 comments

Comments

@vesparny
Copy link
Owner

vesparny commented Feb 3, 2015

Morpheus is highly coupled to fluxible.
I really enjoy it, but I think a much more vanilla solution would be the best solution.

In order to get rid of fluxible, we will need to face some problems:

  • replace the routing fluxible solution with react-router
  • replace fluxible with some other flux lib
  • restore the WebApiUtils. look here

@acdlite any thoughts ?

@acdlite
Copy link

acdlite commented Feb 3, 2015

Obviously I'm biased, but I think Flummox hits all your requirements perfectly. One nice thing about Flummox which may not be noticeable at first is that since it's self-contained, you can replace your old Flux stores and actions one at a time — in other words, have both Fluxible and Flummox stores running side by side during development until they're all replaced. (Does that make sense?)

Also, in order to get feature parity with Fluxible and alt, I need to implement dehydration/rehydration. I've opened up a new issue to track that on the Flummox repo.

acdlite/flummox#5

@vesparny
Copy link
Owner Author

vesparny commented Feb 3, 2015

I'll try to work on it thanks.
Do you think it will work well with immutable.js?
Was wondering about integrating it for stores handling.

@acdlite
Copy link

acdlite commented Feb 3, 2015

Yeah, absolutely. The state API for Stores is designed to be very similar to the API for React components. Here's an working example I made just this past weekend on an internal project for work: https://github.com/parisleaf/parisleaf.com/blob/develop/src/shared/stores/PageStore.js

Eventually, you could even create a new class ImmutableStore that serves as the base for all your stores. I think there's lot of potential for this pattern (+mixins) as a "plugin" strategy.

@vesparny
Copy link
Owner Author

vesparny commented Feb 3, 2015

Thanks, I'll take a look.

I just came through this: https://github.com/goatslacker/iso/blob/master/examples/react-router-flux/server.js
It's an Alt side project and I think it covers what you did by making flummox singleton free.
What do you think?

@acdlite
Copy link

acdlite commented Feb 3, 2015

The bootstrapping part is definitely nice, and next on my list to implement in Flummox.

But it's using a singleton

https://github.com/goatslacker/iso/blob/master/examples/datetime-flux/src/alt.js

so you're forced to have this awkward separation between user-specific data and regular data. Flummox's approach is far more straightforward, in my opinion. It removes isolation as a concern so you don't have to jump through so many hoops.

I'll start work tonight to get an example up to show you what I mean. Can't make promises on a timeline though, because I'm in the middle of another project. Hopefully by end of week.

@acdlite
Copy link

acdlite commented Feb 4, 2015

I've (rather hastily) thrown together a demo of an isomorphic app using react-router, Immutable.js, and Flummox.

https://github.com/acdlite/flummox-isomorphic-demo

Super basic and needs more attention, but it works. Maybe this will help you out until I find time to work on the docs / make a better demo :)

@vesparny
Copy link
Owner Author

vesparny commented Feb 4, 2015

Hey, thanks for your hints.
They'll be helpful for sure.
I'm quite new to es6 syntax, do you have any good reference to get started about this topic?

Thanks man

@vesparny
Copy link
Owner Author

vesparny commented Feb 4, 2015

@acdlite the process has started :)
I just switched from browserify to webpack in the development branch

@acdlite
Copy link

acdlite commented Feb 4, 2015

6to5 has a nice overview: http://6to5.org/docs/learn-es6/

https://github.com/getify/You-Dont-Know-JS is also a really great resource.

This was actually my first webpack experience. I still <3 browserify, but react-hot-loader alone is worth the switch.

@vesparny
Copy link
Owner Author

vesparny commented Feb 4, 2015

yes, but webpack is also awesome because it supports dynamic require.

See how many if statements I removed :)

@acdlite
Copy link

acdlite commented Feb 4, 2015

Oh wow. Yeah, in my experience gulp + browserify/watchify was never a good combo. browserify works best via the cli. (That was my original motivation for abandoning gulp and just using make, but that's a separate topic, haha.)

@vesparny
Copy link
Owner Author

vesparny commented Feb 4, 2015

I'm trying now to remove gulp watchers in favour of react-hot-loader.
But honestly I don't see the benefit over just rebuild the bundle then reload the page. Am I missing something?

@acdlite
Copy link

acdlite commented Feb 4, 2015

With react-hot-loader, your app maintains its entire state on update. This is awesome if you're working on anything interactive, like animations.

But I agree, for the most part, watchify + livereload (or browsersync) is perfectly fine and almost as fast. Hot loading is just nice to have.

@vesparny
Copy link
Owner Author

vesparny commented Feb 4, 2015

For today the switch to webpack is enough :)

I'll start soon looking at your examples

@rmahoney-bl
Copy link

very interesting conversation -- thanks guys!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants