5 ms·
When I started using React on a commercial project a year ago, I was totally uninterested in upfront adoption of technology other than the minimum required. So
by mbrock 11y ago
When I started using React on a commercial project a year ago, I was totally uninterested in upfront adoption of technology other than the minimum required. So I eschewed all the Flux stuff and just used a single nested record of app state updated with the simple built-in immutability helper. We put everything in just two or three files so we didn't need any complex build tooling. We did routing by just listening to hash change events. We got up and running very quickly and fleshed out the app in a couple of months with no major problems. Later we've started using some stuff, but we did it gradually according to real needs.
So when I see people starting their projects by configuring dozens of tools and technologies that they don't really need up front, I wonder why they don't just start simple.
- chvid 11y agoExactly. The problem is when people ask themselves "What do I need?" and then go "I don't know ... hmmm ... I better get everything then ..."
- eva1984 11y ago+1 A lot of dev, like me in the college, have the tendency to get everything right before starting writing first line of code when learning something new, in hope that orthodox practice will help avoiding pitfalls on the way. But what I really learned along those years, is that pitfalls are inevitable, and expose yourself to them at the early phase of learning is helpful so that you could later appreciate other people's solution and the reasoning behind. Trying to get everything right from beginning hinder you from getting such first-hand and organic insight, and wondering with tools too much will stray yourself from focusing on the essentials.
- cageface 11y agoReact is still pretty new and doesn't really proscribe anything beyond the view layer. So when people jump into it they go online to try to get an idea of how they should structure their apps they find a lot of buzz around things like Redux and React-Router. Those are both good tools but the combined learning curve for those + ES6 + Webpack + Babel can be pretty steep. But, like you say, for a lot of apps you can start with a much simpler stack. I did the same thing when I was getting started. My "stores" were just simple JS objects with some subscribe methods. This worked well enough that I was able to focus on building my app and to see first hand how great the React model is for building UIs.
- mbrock 11y agoYeah. I guess I'd recommend a patient approach of first making sure to learn what the library itself does, and then being cautious about importing too much stuff up front. Because that does lead to fatigue and confusion.
- jskulski 11y agoExactly. My experience with JS (which is entering non-trivial amounts) has been this: Either get a boilerplate, generator or spend frustrating afternoons configuring to the start line. Then once you start work spend hours reading docs to figure out what all that stuff you installed actually does. OR Build from scratch, build the simple stuff, then when your brain says 'hey someone must of done this', look for a library and plug it in. Then at least you understand a general idea of what you're installing. An over simplification, of course, but building rudimentary routers, event managers, mvc structures etc helped me immensely.
- dev360 11y ago"Two or three files" can also be a terrible idea if a project mushrooms. Nobody wants to wade around 2000 loc files just because its missing tooling, but I can def see your argument.
- mbrock 11y agoMaybe not. I don't mind, I have incremental search. For me, wading around 200 files in subdirectories is more tedious. But it seems to be a matter of preference.
- ebola1717 11y agoWe have 1 file per react component, and keep our files down to < 200 loc (and we're still using es5). As long as you define your components before mounting any of them, you don't have to worry too much about dependency order.