This could be debated, atomic components within a framework built for a purpose can still be responsive.
Responsive or adaptive should be choice made at the start of projects and then ideally followed through till the end.
We choose responsive and made atomic components so it can work, but... it has to be in the thought process from design to implementation, the same can be said about adaptive.
Source: Our UI is complex, large, responsive and serves 3 million users and won awards.
If you support ES6/ES7 in your build cycle then we are big fans of the spread operator which can be used instead of _.default, Object.assign. For example:
case 'CHANGE_LOCATION':
return {
...state,
location: action.location
}
For a simple app your code works fine. You will have trouble when it scales.
We have migrated a load of model logic from Angular to redux and redux saga, once you get your head around a nice structure then its a dream.
I created a gist for you to check out [1]. Maybe also check out the concept of Redux Ducks [2]. I now find our code easy to read, share and test - unlike our massive Angular app.
Also as somebody else comments, you should make sure the only way you talk to your store is through a reducer dispatcher.
Regarding component states, find some reading on components v containers [3] - we even have 2 separate folders for the different types. Once mastered and implemented, most components are small and again easy to test.
FYI, I've got links to a number of actual Redux-based applications at https://github.com/markerikson/redux-ecosystem-links/blob/ma... , including Jenkins' new management UI, Firefox's new debugger, Wordpress's new admin page, the popular HyperTerm terminal application, and more. Twitter's mobile page is also built with React and Redux.
We have an pretty large production app w/ React & Redux.
In some ways it is initially a lot of boilerplate for various state reducers, but after everything is there building really functional features is extremely quick with redux; just from a developer's time point of view.
I rarely comment for the amount of hours spent parusing HN but this is one to many shoddy node bashes.
I take a pragmateic approach to this (maybe its cause im now predominantly a JS developer).
It does feel like every man and his dog want to build a website and putting together some resemblance of a webpage with HTML, CSS and JS (and maybe a one click install) is not actually a steep learning curve for the majority.
From experience of interviewing I know this is the start of a lot of Front End/Node Developer careers, this is cool, but i think it also mean the quality of JS developer is across a spectrum is more weighted to lower side, most having none or very little knowledge of patterns or "production" level coding. Because of these the JS world is full or gists, blog articles and NPM packages at a similar lower level of quality. Something very easy to bash.
I also feel there are developers from other languages that try Node and fall into patterns that rubbish articles say, panic cause it wrong and bash publicly Node.
For example....
- Node.js's "callback hell" async paradigm is probably the worst of any popular language/framework today.
Yes, as cool as it is that you can pass a function (with context) around between another function for hours, some people sadly use it wrong. Promises, Async, Generators, Redux Saga all solve these issues.
- Ignoring the fact that JavaScript lacks static typing, its inconsistencies make it a pain even compared to Python or Ruby. It's so bad that entire applications are written in CoffeeScript and transpiled just to avoid JavaScript.
Yep, I been using JS in many forms, including coffeescript for 15 years, it lacks static typing, you either love it or hate - its not a hindrance. I love using ES7 over coffeescript now.
- NPM is an absolute clusterfuck. It's a matter of "when," not "if" your application will break because a dependency violated semver. Oh, and good luck developing offline.
Yep this public package manager has some rubbish in it and yep people "could" screw you over with package versions.
Putting the correct version numbers in your package.json and having your own NPM repo like Nexus get rid of these issues.
- The over-engineered UI frameworks and tooling have bled over and poured gasoline on the clusterfuck.
I can say, after doing this for 17 years - I love Webpack.(Finally my folder structure of a website is poetry, and my CSS has all the right browser prefixes when required). Tools like webpack, gulp and grunt help with this. Yep it can go crazy, but for me it really does not take that long to setup tooling to the exact what i want.
- A community with the attention span of a goldfish
Yeah probably, but can not actually see why this effects me.
- Scaling is a pain in the ass.
What?
- I've found that most people who think Node.js is a good platform lack experience.
I have 17 year experience from Perl, Python, C#,Java, ASP, Ruby, PHP and more. I have worked for one of the big tech companies. I dont lack experience, Node JS comments like yours do though.
- If you're just starting programming or you started with another dynamically-typed language, then I would highly recommend learning literally anything other than Node.js. For a HTTP server, try Python+Flask, Ruby+Sinatra, Go+Gorilla,Gin,Goji,etc., Scala+Akka-HTTP, Java+Dropwizard, C#+Nancy, C+libonion, ...
If any good programmer does not choose the right tools for a job then your not good. Node does not solve everything.
> Promises, Async, Generators, Redux Saga all solve these issues.
I'm aware of all of these and group them in with "callback hell." "Solve" is being overly generous. Generators are the best but still feel shoe-horned in and clunky.
> you either love it or hate - its not a hindrance. I love using ES7 over coffeescript now.
Yet another example of a language that you can't actually write a Node.js application in without transpiling...
> Putting the correct version numbers in your package.json and having your own NPM repo like Nexus (live Java) get rid of these issues.
So basically "don't use the system as intended" lol
> What?
Scaling is a pain in the ass.
> If any good programmer does not choose the right tools for a job then your not good.
This is an oft parroted phrase (usually by over-zealous project managers) to justify using some trendy new technology as though people hadn't been able to write HTTP servers until last year. There is more in common with all of those options I listed than there is difference. Twitter was serving millions of users before migrating away from Ruby on Rails. Instagram and Pinterest are in the top 50 most visited sites in the world and still both use Python+Django. If any programmer can only get the job done with a single tool, then they probably aren't that good.
I have had a Sinclair, Amstrad and Pi 1 - in fact I had my first experience of programming on my Sinclair when I was 8 years old. Now make a living out of it. Will be getting a Pi 3 and finally get around to making my connected house.
