A general and practically simple request for feedback

[bowheart]

Hey, all!

As Zedux ramps up for its first pre-release (v0.1.0!), I just wanted to make a general request for feedback. Feel free to comment on this issue.

Some idea sparkers:

• How are you using Zedux?
• Do you see any flaws in the api? Anything that's unnecessarily difficult to use/remember?
• Is there any documentation that's unclear?
• Are there any examples you'd like to see?

Of course, anything else feedback-ish is welcome.

This is the beginning of Zedux. Let's make it awesome! :zap:

I guess I should probably post some "known issues": The official react bindings are coming soon. And they're pretty sick. I'll create a react usage guide when that's finished. Better support for the Redux dev tools and hot reloading are also in order. The zero configuration guide needs beefing up. And store.setState() needs to be documented. I think that basically sums up the current roadmap. Most of these will be done before the first pre-release, which will be in just a few days :open_mouth:.

[magnusjt]

Haven't tried it yet, but just wanted to say that I really enjoyed the readme :)

[bowheart]

Hah. Why thank you. I rather enjoyed writing it. :grin:

[bowheart]

I suppose I should retract my premature statement that the first pre-release would be in just a few days. That was 15 days ago, so I think it's disqualified at this point. Here's an update on what's going on:

The official React bindings are done! I have a few api additions for them, but they're done, tested, usable, documented, the works. Check them out!.

An item on my todo list was to clean up the reactor hierarchy creation model. It was previously erasing the hierarchy and re-creating it from scratch every time store.use() was called. While not a big deal for the first pre-release, this algorithm could clearly be improved to only re-create the necessary pieces of the reactor hierarchy.

Long story short, I also discovered a memory-leaking bug with the naive store.use() implementation, so its fix got moved to top priority. That overhaul was my project last week and is now done and stable as of f801207e961d581fb5f133f2f57b13c8d76afc52. Zedux now has an intelligent tree diffing algorithm for crazy-fast hierarchy merging. And no memory leaks.

The repo examples also got some love.

The zero configuration guide has been beefed satisfactorily.

store.setState() has been documented.

Current Roadmap:

• There's one small bug with selectors. That'll need a fix, a previously-failing test, and some mention in the docs.

• State machine processor hooks need to behave like ZeduxReactor processors – they should handle iterators and observables.

• I need to write the React usage guide.

I've also been experimenting with some effect-based models for processors. They're looking pretty cool! But I don't think that'll be a v0.1.0 thing.

Anyway, just a few tiny fixes and a doc page before v0.1.0. That'll be just a few days, right? :crossed_fingers:

[imbhargav5]

Incredible. I had the exact same idea and wrote a library (it's called finite-store) where you can use finite state machines instead of Reducers and have data coupled with the state machines. So instead of value just incrementing from 1 to 2, it checks if you are actually if the transition is valid and if it should run the transition(or action). But I found out that it was getting complicated soon. Middlewares and transition dispatches brought more learning curves and I was not sure how to pursue it further. But I think you did a tremendous job at doing it and doing it better. Great stuff!

[imbhargav5]

Examples that I would like to see

• I would like to see an example with nextjs. In fact, I would be happy to contribute to it!
• Universal rendering
• Router integration

Potential Flaws

• Middlewares? I couldn't find anything about middlewares in the Readme

The other flaws are mostly centred around learning experience. The idea and implementation are fantastic, but when you are a web developer who has just started with zedux, I feel that it should have a more promiment set of defaults which the user can just start using right away.

Even a convention will do I would say (something which zeit does with nextjs).

Learning experience directly impacts package usage in my opinion and I think that's a good area for the package to improve upon.

[bowheart]

@imbhargav5

it should have a more prominent set of defaults

Good, good! I totally agree. In fact, the latest version of React Zedux has a StoreApi class that is an attempt to standardize store creation for consumption with React's new context api.

Since store consumption is very dependent on the environment in which Zedux is used, I think it makes sense to have those sorts of conventions live in environment-specific plugins. Like React Zedux.

As far as folder/file structure conventions go, the docs definitely need a more prominent suggestion of how to organize Zedux code. But I'm still figuring this out. I've been using Zedux for a couple months now and have switched how I organize it several times. I think I'm just waiting till my own preferences calm down. But definitely open to suggestions.

I agree with all those examples. I'll start working on the router example for sure. Next.js has been on my to-do list. I'll definitely look into it, but you can totally create the actual example for the Zedux repo. Like, I would be stoked if you did that. It would, of course, not use parceljs like the other examples, so the main examples readme would need some re-wording.

next-redux-wrapper would work for a single, global, Redux-style Zedux store. Well, it would if it didn't have a strict peer dependency on Redux and React Redux. But other than having to create a whole new plugin just to make it import Zedux instead of Redux, the other hurdle would be handling composed stores. Especially since stores should have the ability to be attached to the root store in a separate, code-split bundle. That's where I need to do some digging. But I'd think it wouldn't be too hard. In React Zedux, stores are treated almost like normal components. In fact, that brings up the next point:

Middleware has been specifically avoided in Zedux. There's a note about it in the overview doc page. But that should probably have some mention up-front in the readme itself. Something containing:

Composition > Middleware

This is a core philosophy of Zedux. The Zedux architecture is patterned more after React than Redux. React components, of course, don't need middleware because composition covers all the bases. And much more elegantly than Redux. This is what Zedux aspires to. Think of a Zedux store more like a component.

And did you delete the finite-store repo? I found the bundled module on unpkg, but I'm not too keen on digesting compiled code before dinner. ;)

[imbhargav5]

Ah Stores as components? So that should also mean that you should be able to create higher order stores or wrap some behavior on to stores. For people to be able to use sentry or raven to log actions on analytics servers. Perhaps that would also be a good example to have.

Actually finite-store has been a private repo until now. Let me share that with you. :)

[meatwallace]

haven't used it, but i was very impressed with the quality of absolutely everything about this project. well done :^)

[bowheart]

@meatwallace Thank you! Always good to know your hard work is appreciated. :)

@imbhargav5

you should be able to create higher order stores

Yep! Here's a proof of concept:

const withLogger = wrappedStore => {
  const loggerStore = createStore()

  loggerStore.inspect((storeBase, action) => ({
    next(newState, oldState) {
      console.log('received next state:', action, newState, oldState)
    },
    error(err, state) {
      console.log('action threw an error:', action, err, state)
    }
  }))

  // The magic:
  return loggerStore.use(wrappedStore)
}

const rootStore = withLogger(createStore())

This won't quite work (currently) as-is. Allowing inspectors to return observer objects is on my to-do list. But you can see the power of composable stores:

export default compose(
  withLogger,
  withSentry,
  withImmer,
  withDevTools
)(rootStore)

(Wow! I haven't actually put that in writing before. Isn't that sick?) I will definitely work on a real example showcasing this.

And thanks for the access! Ah, I see the complexity. I put together this jsfiddle to compare finite-store's "github users fetch" to a Zedux state machine implementation. Zedux accomplishes it with about half the code. Hmm. I'll try to pin down some reasons:

• Zedux doesn't necessarily care about the transition name, just the target state.
• Zedux offloads all other data storage to normal reactors. The machine is just responsible for handling the transitions themselves. This simplifies both aspects.
• Zedux states are also actors (action creators). So we can do cool stuff like compose(dispatch, requestSuccess).
• The Zedux processor layer handles the thunk. No assembly required.

[imbhargav5]

Ahh. I think the part where Zedux doesn't care for the transition name does kill a lot of complexity.

[cjk]

Have been looking for a better redux for some time and apparently found it in Zedux :100: I'll base my next Web-App on it, which will definitely also use Next.js, so I can second most of what @imbhargav5 said. I don't feel confident in being the one writing a zedux-wrapper for Next.js, but if nobody else does it before me, you've been warned :see_no_evil:

[bowheart]

@cjk I am warned. :smile:

I'll be honest, the zedux-wrapper for Next.js has fallen pretty far down my todo list. I'm currently working on two projects called zedux-sync and zedux-graphql as they're more relevant for my teams and the projects we're working on right now. I might get to it...someday...but don't let that stop you! I'm sure you're as qualified to write it as anyone.

By the way, I recently refactored one of my client's Next.js projects to use React Static. If you're creating a static site, I can't recommend React Static enough. Zedux works out of the box with it. Among (lots of) other things. :slightly_smiling_face: But it depends on your use case, of course.

Anyways. Thanks for your interest in Zedux! If I know we have something of a community going, I'll start being better about managing issues, tweeting tips, and maybe even blogging. :open_mouth: Enjoy!