"By now, you’re convinced: This idea deserves to be heard."

This week my first public project got 7 git stars. The feeling is fantastic. I don't have homepage or story, but I have a nice diagram :)

The question for me is why I'm releasing this, to feed the ego monster or because I really beleive it's worth it? I hope it's not the first, but not sure, tbh.

It might as well be a combination of the two, but to be honest I don't think it's an issue. If those ego boosts are what keeps you building something useful, that's great and you probably deserve them.

It's a bit like social networks for exercise (Strava etc) - the whole thing is just people looking to show off because they've exercised, but if that's what's keeping them in shape, then great!

As a side note, I think you'll get a whole lot more stars with a screenshot and a one line description in the readme (before the mobile github fold for readmes)

Hi, I have exactly the same conclusion as you - you can check my demo todo app - where the UI is an extension to the app. I'm having React and Mustache renders to demonstrate how the view is totally decoupled from the app logic. It have SSR, both for React and Mustache, Service worker for offline usage. Redux for state management. I'm using typescript.

https://drmzn-todo-app.herokuapp.com/

https://github.com/max0xff/drmzn-todo-app

https://github.com/max0xff/drmzn-todo-app/blob/master/About....

I would love to hear your feedback :)

That diagram is wonderful, every part of it makes sense. I also liked how you describe the "lifecycle" step by step. In a way, it made me realize how the Redux pattern fits in with an evolution of MVC.

I think I'm similar to you, in that I've been developing my own solution to manage the whole app lifecycle in a way that makes sense to me, with a library of (mostly) my own modules so I can reuse it across all apps I build.

At the same time, there's value in following "community standards", generic libraries and patterns that most people are familiar with. So, I'm a bit torn on creating my own patterns/utilties versus adapting existing ones that everyone's using.

Thank you so much for checking it out. I'm so happy that diagram makes sense to you.

One of my favorite talks is from Robert Martin, the first link on the bottom of the about.md - when he explains the history of MVC, I realised that the original idea for MVC is exactly what Redux is. But in the years people changed the meaning of MVC and that's why now it seems different. For me, Redux is 1:1 as M from original MVC docs from the 70s.

I'm also torn on using "standards" vs my own implementation. I feel kinda like an outcast, using my own "framework".

Side joke: With hooks and functional components, the React community is moving in our direction. I cannot wait for the next logical conclusion - Lets move the hooks out of the components :)

I would like to see some of your code, if you like to share it, please send me an email: alex.tzvetanov at gmail com

Thank you again for spending time on my code and thanks for the feedback!

Really sorry to call you noob. You may have more experience dealing with Redux codebases from me, but in any case I was arrogant and I'm sorry.

Example of "action-reducer" - combine action and reducer as one IIFE. Use object-path-immutable to update the state.

In any action.ts file you can have as many actions as you wish. Every action has type, dispatch and reduce methods:

  export namespace indexSaveSsl {
    export const type = 'INDEX_SAVE_SSL';
    export const dispatch = (store, response) => {
      store.dispatch({
        type,
        data: response.data
      });
    };
    export const reduce = (state, action) => immutable(state)
      .set('Reports.data.ssl', {})
      .set('Reports.data.ssl.result', action.data)
      .set('Tools.options.ssl.test_running', false)
      .value();
  }

This is typescript namespace, but compiles to IIFE.

This is how actions is combined:

  export const actions = (() => {
    // import main actions via webpack
    const actionsMain = require.context('app/', true, /actions\.ts$/);
    const mainFinal = actionsMain.keys().reduce((prev, key) => Object.assign(prev, actionsMain(key)), {});
    return mainFinal;
  })();

You can call it:

  actions.indexSaveSsl.dispatch(store, resultSsl);

And here how to generate reducers from actions:

  const reducer = (state = {}, action) => {
    // main reducer
    const result = Object.keys(actions)
      .filter((item) => actions[item].type === action.type)
      .map((item) => actions[item].reduce(state, action));
    return result[0] || state;
  };

  createStore(reducer, hydrate, extension);

No switch statements and reducers.

When Redux stops to buffles you, might be the good time to give advice about it. You might implement it 20 times, but if you don't understand it, every time will be pain. Redux can be life saver even for single developer, so team size dosen't matter.

Would be funny to say, I've tried 4 times to tie my shoes, but didn't go well, so you shuldn't tie your shoes...

So much hate, whithout any reason is what buffles me.

I would be happy to show you how to use redux, without switch statements and even without reducers. It's not that hard, and if you don't like it, just use other state management libs. But don't call it poor design - it has 2 methods.

Can you point to any writeups on this? Would love to reduce the boilerplate a bit, while still needing a global state management tool for a smaller app.

Hi, I'm a Redux maintainer. Here's a few resources.

First, the docs already have a page called "Reducing Boilerplate", which shows patterns like writing a function that accepts a lookup table of reducers [0].

Second, a while back I wrote a pair of posts called "The Tao of Redux" [1] [2]. Part 1 discusses the implementation and intent behind how Redux is meant to be used, and Part 2 looks at why common usage practices exist. As part of that, I pointed out that you can use whatever logic you want in your reducers, and as much or as little abstraction on top of Redux. Switch statements are simply the most obvious way to handle multiple values for a single field, but you should feel free to use whatever approach you want.

Third, we've recently created a new package called `redux-starter-kit` [3]. It helps simplify several common use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once without writing any action types or action creators by hand. I'd encourage you to try it out and let us know how well it works for you.

Please let me know if you've got any other questions I can help with!

[0] https://redux.js.org/recipes/reducing-boilerplate

[1] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...

[2] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...

[3] https://redux-starter-kit.js.org/

This is great, thanks so much

Hi, if you mean how to get rid of switch statements, you can check my comment bellow - about "action-reducer".

I've seen https://github.com/erikras/ducks-modular-redux and it's close to what I do.

Also you can check - https://github.com/reduxjs/redux/issues/1167#issuecomment-38...

Thanks so much, I love the pattern in the second link you shared