Don't you want to add Immutable.js?

[liesislukas]

Hey, great job! I've currently started 2 projects on your boilerplate. It's great, I love the structure of code and selected tools. Only things what I change is get rid of flow and "models" folder and add Immutable.Js. Why do you need models? For flow? If reducer, actions, selector, constants are in one place, why the structure of the initial state is somewhere else?

On features/X/x.js i define initialState like this:

const initialState = Immutable.Map({
  loading: false,
  channels: Immutable.Map({
    channels: Immutable.Set(),
    product_id: null,
    error: null,
  }),
  product_id: null,
  error: null,
});

and in the component, I can have super quick check of the immutable structure

  shouldComponentUpdate(nextProps, nextState, nextContext) {
    return (
      !Immutable.is(this.props.countries, nextProps.countries)
    );
  }

I've used Immutable.js for months before and it was always great. I suggest to try it out. Flow can be used with Immutable too, but I don't feel, that I need flow in the 1st place. I would if I would work on the huge app, though.

[nicksp]

Hi @liesislukas

Wow, i am so happy this project is valuable for fellow programmers. Cool to know that what you did has served a good job for the community. I'll definitely keep it updated with more useful things in near future...so that it's even more handy for you :)

Speaking about static typing.... i'm still thinking about its value to project in general, so might reconsider some things in the next update.

As for Immutable JS, i truly believe it should be considered on a project's basis. So it's not for everyone and not for every case, thus i don't want to include it to the boilerplate...

If you decide to open-source the projects you mentioned before, i'd love to take a look under the hood ;)

Cheers

• Nick

[liesislukas]

I actually decided to show the source of my own project 👍 here it is:

https://github.com/liesislukas/geekystats.com_ui

while I've done it all in 2 days time and it's not a complete application, but at pre-alpha stage now, there might be crazy stuff. But you definitely can see directions I take. I'm not completely sure about your structure of features and components. As you can see I've left a 404 handler at components while putting everything else into features. Also, some features depend on others so actions might be fired from any component of any feature. If some feature would be removed there is a chance of firing actions that do nothing, not sure if that's a big problem, though. Might add some tracking mechanism if the state was completely unchanged after action fired, maybe it's worth looking at it to check if it's not dead-code. That's not an issue at an early stage, but still looking forward.

By the way, before I used material-ui and now trying out blueprint. Material-ui created a lot unneeded DOM elements (might be fixed already, I used it a year ago) and I had ui which lagged a lot because of that. Now I've created small chrome extension to track dom elements on the page. It's kinda interesting for me if you want to try it out, check this: https://chrome.google.com/webstore/detail/dom-count/dfghopdediaeajjejpjgeapfkbkhelio Here is the code if you'd like to see: https://github.com/liesislukas/chrome-extension-dom-count nothing fancy :-)

[nicksp]

@liesislukas Thanks for sharing, that's really great app with lots if interesting things happening in a codebase 👍. Will definitely check those when have more free time :)