9 ms·

Honestly I don't know how I learned React. It's not fun at all. Oh sure, the basics of React is not too hard. If you ignore all the outdated examples and code (

Honestly I don't know how I learned React. It's not fun at all. Oh sure, the basics of React is not too hard. If you ignore all the outdated examples and code (using var, no JSX, overusing component lifecycle, not using functional components). But then learning Redux, React Router, React JSS, Reselect, Redux Thunk, Webpack, etc., is just terrible. Sure, there are tutorials for each individual library, or maybe even two or three of the libraries at once. But combining all of them and making sure that it's not a total mess of code is like trying to play QWOP with your code. Now that I have everything compartmentalized and understood, it's pretty easy. But getting there is a long long journey. I've played around with an idea for a tutorial on modern web development that starts with just basic JS DOM fiddling, then introduces various features and techniques as they're needed. So you'd start with just using old school document selectors. But then, as all the getElementByClassName calls become annoying, maybe you'd introduce transpilation, so that you can querySelector with a map/filter. Then, as the updating starts to get hairy, you could introduce a library like React. As state becomes an issue, Redux. But the point would be to start with the basics and build up an understanding of why we need these libraries. And what problems they solve and what problems they don't solve. But of course, the moment anybody writes this tutorial, half of it will become outdated. Ah well.

tptacek 8y ago
So don't use Redux, React Router, and Thunks. I don't even know what React JSS is. Use create-react-app's tooling. Even Redux's author tells people Redux is overused. A pretty big percentage of the value of the flux pattern is just in having an event pubsub system, so if your application is so complicated that you really feel like you need to structure it, you can just use EventEmitter. I frankly don't understand the popularity of React Router. The core thing React Router accomplishes can be done in ~50 lines of code including the switch statement for "routes". If you like and grok React Router, use it. But I don't think it's a good idea to push through your resistance to it.
- gorpomon 8y ago
  I mean this in a nice way, I'd really appreciate a gist showing how you get the core concept of react-router in 50 lines. It's in a project of mine now and maybe it shouldn't be.
  - mieseratte 8y ago
    Well, it really boils down to const path = findThePath(); class Router extends Component { render() { if (path === "/about") return <About /> else if (path.match(someRegex)) { const data = parseSomePath(path); return <Page { ...data } /> } else { return <Default /> } } } Seems as though React Router has gotten a bit complex because it's abstracted away from the concept of a webpage, such that one can use it in the browser, or React Native (which can be a number of environments). Of course, I say just buck-up and learn the damn thing, it isn't that complex... earn the "Engineer" in your job title! Maybe I'm just an out-of-touch neckbeard these days?
    - danvayn 8y ago
      Just a small addendum to your post -- you shouldn't use react router for react native, you should use react-navigation for that (https://reactnavigation.org/ https://reactnavigation.org/).
      - mieseratte 8y ago
        Fair enough. I'm not particularly qualified to speak about React Native, having only done toy apps.
      - connorelsea 8y ago
        I use react-router for native and there is a react-router-native package. You "shouldn't" listen to randos on the internet when they are demanding what you use or don't use.
    - sli 8y ago
      React Router v4 is particularly difficult to get used to when compared to earlier versions. While I don't much mind it (I get it working, then I don't need to touch it anymore), it definitely took me some time to wrap my head around it. So yeah, it works good when you get it working, so yeah, the best thing to do is to just buck up and learn if it you need it. But boy does it suck getting there. All of that said, I don't understand where this view comes from that Redux is extremely confusing. It can indeed sprawl a little. Say, if you keep you containers, reducers, and actions in their own directory trees. The overall architecture didn't take me very long to grasp and start to leverage. Plenty of folks find their home in Flux or MobX instead, but I'd have to guess that a lot of the confusion is actually confusion about state containers and their uses.
- icc97 8y ago
  > Even Redux's author tells people Redux is overused. I believe this is the post [0] in question. [0]: https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
- _hardwaregeek 8y ago
  You're not wrong for beginners. They shouldn't use all or any of these tools starting out. But when you reach the point where you understand React and you start to reach the limits of React's features, i.e. inline styles isn't cutting it anymore, setState is growing too big and too complex, etc., that's when it starts to get hairy. Because continuing down the path of pure React is painful, but learning all these damn libraries is also painful. That's where a lot of people get lost imo. Not to mention the times where the codebase predates you. My first experience with React was on a codebase that was pretty horribly managed. Basically a combination of magpie developers and a total lack of understanding of React patterns. When the developers are finding and trying to integrate the next new shiny lib every other week, it becomes a nightmare for any new developers.
  - JamesBarney 8y ago
    I think far more people get lost trying to learn the libraries than grow an app to a size where pure react too painful. First time I used react I hated it, because everything was done through flux, want to add a field to a form. Now you need to update 4 different files and create 8 methods. Not to mention interacting with non-react components in a react way can be super painful. It was insane. Second time I dropped all of the libraries. Only used react, and any time I needed to use a non-react component I wrapped it myself, and many times did very unreacty things like use methods to do a lot of interaction. And I loved it. Everything is so much easier. I can focus on solving the user's problems, and not my react problem. The apps weren't huge, but they weren't small either. 3 months of work for 3 devs full time.
    - ericmcer 8y ago
      I had a similar experience with Redux, every event in the app went through redux. Click button > redux event fired > redux updates state > component catches state update > button listener fires. It is a total nightmare and a horrible use of redux. That is like binding every variable and function to the window object because you have no concept of scope.
- rmrfrmrf 8y ago
  > The core thing React Router accomplishes can be done in ~50 lines of code including the switch statement for "routes". This is a pretty common theme for me when considering any react-* library, and I think it says a lot about how nicely React lets you abstract away behavior. As for Redux, I feel like the payoff has been worth it, especially when adding in the benefits of tooling and middleware. When I learned React for the second time, I did it with Redux out of the gate, and while it did take a while to ramp up, the upside was I was able to see immediately where bugs were occurring (React + Redux DevTools) and didn't have to grok the component lifecycle before getting some data on the page.
- exclusiv 8y ago
  Good points. I enjoy VueJS and AngularJS, thought I wouldn't like JSX and React but React and React Native have surprised me. However, Redux looks overblown for most use-cases and takes all the fun out of it. For some cases you can just do a singleton on your shared data component. So for handling a multi screen form it just looks like export const MultiFormState = new MultiFormData(); Then import {MultiFormState} of course... Very useful. Between that and EventEmitter as you noted you can avoid a lot of extra code in many applications and get your components working well without the bloat and mental overhead.
- j-b 8y ago
  Any pointers for someone in my position? I have a million LOC windows forms system that going to be ported to the web. I've reviewed React, Angular, Vue, etc. As a beginner, Vue seems the best to me, however, all of the experienced web developers I talk to recommend React. After reviewing the code and walking through tutorials it just seems like overkill and overly complex but I suppose I'm missing something. It's concerning because I need to have our team port a huge code base and am not sold on React but that's what we're starting with. The developers I talk to say Angular is too complicated and React has good component based features. Nobody has Vue experience. My gut tells me Vue would be better but if I can't find guys who actually use that and have React experience instead then it seems that's the direction to head.
forgot-my-pw 8y ago
Sometimes react ecosystem and all the dependencies feel way too much. Sometimes all I want is to use data bindings, and at those times I just ended up using Vue.
- tptacek 8y ago
  None of these are React dependencies.
- strkek 8y ago
  Same here, but in my case when I need that I usually go with Mithril.js[1]. I found it by chance and instantly liked it. It's a shame that nobody seems to know it. [1]: https://mithril.js.org/ https://mithril.js.org/
  - pygy_ 8y ago
    The framework usage is still growing, though it is dwarfed in popularity even by Vue (which is ~60 as large). We do little to promote it, and hyperscript (the default view syntax, i.e. m('.foo', {...attrs}, ...children) ) is not very popular (even though I prefer it to JSX, which is also supported).
deleted 8y ago
[deleted]
a_c 8y ago
In the pursuit of React, something is added everyday. In the pursuit of enlightenment, something need to be dropped everyday. [1] In the react realm, every problem is solved by throwing another layer of complexity/abstraction/whatever you call it [1] Adapted from https://www.goodreads.com/quotes/175803-in-the-pursuit-of-knowledge-everyday-something-is-added-in https://www.goodreads.com/quotes/175803-in-the-pursuit-of-kn...
- IloveHN84 8y ago
  Like Java/Spring. Why do not use a more simple approach, say jQuery?
  - the_new_guy_29 8y ago
    This question is so wrong on so many levels
    - klibertp 8y ago
      I have a blog. It's a set of static pages, generated offline and served via Nginx. There's nothing dynamic there and the content is perfectly readable in lynx. Once in a blue moon, I want to add a screenshot or other image to a post. Such images are of various sizes, mostly larger than the (max)width of the content. I use CSS to scale them down to fit with the text, but sometimes images displayed like that are too tiny to be legible. For a long time I handled this case by wrapping <img> with <a>, basically like this: <a href="$IMG_SRC"><img src="$IMG_SRC" alt="" /></a> It works, and I like it, but it has a couple of drawbacks, most important being that it's kind of intrusive - by clicking it, you change the current url, and when you get back, even if your browser scrolls the page correctly, you need to find the place where you stopped reading. At some point, I gave up and included a bit of JavaScript, which enlarges the image while you stay on the same page. I used some kind of fancybox derivative - a jQuery plugin. Now tell me that I should've used React.
      - ben509 8y ago
        The choice of tooling has to be dictated by actually delivering a product, even if it's open source. If JQuery met your needs at the time, and your personal preferences and experience are nonfunctional requirements, it was the right call. That doesn't mean that in the future you won't grow beyond that, but having to transition a production system to a new technology is fundamentally a good problem to have.
chubasco 8y ago
I recommend the e-book Fullstack React (https://www.fullstackreact.com/ https://www.fullstackreact.com/) (I have no relationship to these guys, other than being a customer). I have had junior engineers read it in the past to get up-to-speed and it does a great job of teaching all of those technologies together in a way that makes sense and is easy to understand.
- chubasco 8y ago
  Let me also add that it doesn't teach them all at once. It starts from first principles and adds on new libraries as the tutorial apps become more complex.
tootie 8y ago
I found react to be extremely intuitive and easy to learn. Redux and react-redux are horribly non-intuitive. So much boilerplate and meaningless terminology and stringly-typed objects. I avoid it.
- pknopf 8y ago
  Switching from Redux to Mobx dramatically decreased my mental load. It is much more straight forward.
  - mephitix 8y ago
    I want to learn Mobx. I like the conceptual model (functional, immutable) of Redux though - I'm just not a fan of all the boilerplate although I understand why it is there. What's your take on things you miss from Redux now that you've switched over to Mobx?
    - pknopf 8y ago
      > functional, immutable mobx-state-tree is what you are looking for. You can model it similar to your Redux setup. It is immutable. It also has the snapshot stuff Redux has.
- mieseratte 8y ago
  React is just mapping data to XML, which may or may not end up as XML (React DOM vs. React Native). Throw in a component lifecycle, and you're good to go. Sure, it's not jQuery simple but for a modern SPA it's about as good as it gets. It allows you to just deal with things in terms of composed functions which is wicked elegant, and since you're almost surely thinking of your page and application hierarchically it maps to reality nice and clean. Redux makes managing global / central state reasonable, and in conjunction with the `connect()` function allows you to A) pull in needed global state and B) dispatch data to be centrally processed such that your component gets to not give a shit. It'll just update as-needed. It's dumb. Strings for types sucks (it's better with Flow, or Typescript I assume) but it is what it is... the immutability can also lead to some subtle bugs if you fuckup and mutate something, but overall I'd rather write a React app with Redux than without at this point just for ease of reasoning about the system as a whole. If you've never dealt with this type of architecture, it can be strange at first but it makes managing state / data flow much easier. [0] - https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0 https://medium.com/@dan_abramov/smart-and-dumb-components-7c...
mephitix 8y ago
>> But the point would be to start with the basics and build up an understanding of why we need these libraries. And what problems they solve and what problems they don't solve. This is exactly what the well-written official React docs do. It doesn't involve any CSS-in-JS, Redux, Thunking, Webpack, etc. 1) Start off with a basic app - build the Tic-Tac-Toe app through the official React docs 2) Build a simple React app with the official CRA (Create-React-App) tool 3) Build a more complex app 4) Keep building a more complex app, learn about routing, lifecycles, performance... N) Look into Redux if you need it --- Re. Redux: The React docs have jumping off points throughout this process to understand why setState-based state management can get difficult in large applications (prop drilling) and the problems Redux solves. Look at this excellent doc on 'Lifting State Up' (https://reactjs.org/docs/lifting-state-up.html https://reactjs.org/docs/lifting-state-up.html). This makes you go through the motions of setting up a component with setState, lifting state up, and experiencing prop drilling. Redux isn't even mentioned here. Re. Thunking: In the 'Basics' section of the Redux tutorial (https://redux.js.org/basics/actions https://redux.js.org/basics/actions), here's an excellent snippet: "Action creators can also be asynchronous and have side-effects. You can read about async actions in the advanced tutorial to learn how to handle AJAX responses and compose action creators into async control flow. Don't skip ahead to async actions until you've completed the basics tutorial, as it covers other important concepts that are prerequisite for the advanced tutorial and async actions." Re. Reselect: Again, in the Basics section, in "Usage with React" (https://redux.js.org/basics/usage-with-react https://redux.js.org/basics/usage-with-react): "These are the basics of the React Redux API, but there are a few shortcuts and power options so we encourage you to check out its documentation in detail. In case you are worried about mapStateToProps creating new objects too often, you might want to learn about computing derived data with reselect." None of these 'power options' and extra tools are talked about in depth in the Basics sections of any of these docs. They are mentioned as jumping off points and the reader is warned not to dive into them early without continuing with the tutorials/docs. This seems to be exactly what you're looking for...
- _hardwaregeek 8y ago
  Yeah, I guess I'm not giving the documentation enough credit here. The main issue I see is all the companies rewriting their applications in React. Because I don't think they see it as a complicated engineering decision with tradeoffs and potential issues. They see it as "we need x buzzword and y buzzword". I'd prefer that the documentation outright say "This is a BAD idea if you're just doing xyz" instead of "if you need, you can check out this". Because it's very easy for developers, especially magpie developers or younger developers to think "oh yeah, of course I need this. I need my app to be S C A L E Able". The idea behind the tutorial would be giving precise problems that are solved by the tools, while also demonstrating what can be accomplished without them. Also, is it just me or is the tic tac toe tutorial really not useful? Sure, it's a good isolated example, but it's a really contrived one as well. Something like an address book or a blog would be a lot more fitting with people's usecases.
tomduncalf 8y ago
This makes me sad as I can’t help feeling that Redux being promoted (earlier on in React’s life certainly) by the community as the de-facto way to manage state has caused a huge amount of pain for newcomers. This isn’t the fault of the Redux authors - it does what it does well, and they’ve always said it’s not intended to be used for everything - but I honestly feel (and have anecdotally observed a few times) that being introduced to the complexity of Redux completely ruins people’s first steps in React (the two are often seen as inextricably linked to newcomers). Personally I feel the community should be pushing people much more towards lighter weight solutions such as component state and MobX for when the application grows. I know Redux has theoretical advantages but in the real world I’ve always found it a large burden and would personally use MobX in preference every time (which isn’t to say MobX also doesn’t have its rough points, but it’s much more intuitive).
- frandroid 8y ago
  So our React site is fairly static, but as it grew we had more and more state to manage across components, and more of it trickling down; in some cases state would come from fairly high up in the structure, and have to be ingested pretty far down the component chain. So as I read the React docs, I discovered childContext, and I started using it. Some of my coworkers would stick to passing props along 2 or 3 or 4 layers down, because every time I'd point childContext to them, they'd point to the part in the docs where it says it's experimental tech and that it could be removed in the future. I'd point out that the React devs have a very sane code-breaking policy and we'd just cross that road when we'd get there. It's not like we're aggressively updating to the latest release anyway. Some other people would suggest using Redux, but would agree with me that we just didn't manage _that much_ state. (We also have a React Native app, and as we manage more state in there, we did implement Redux, though it still bothers me as a tech.) Anyway, fast forward to last month, where I read Abramov explain that Redux actually uses childContext!! So: 1) there's no way they'd just rip it out of React without warning, 2) if childContext works for you, don't worry about the complexity of Redux, just pass down state and a few state-modifying functions in childContext!
  - acemarke 8y ago
godot 8y ago
I feel similar to both OP and you; especially when first learning React a year ago. I feel like the only real way to learn it is to get a job where you work with React full time, and after a few months you will finally get comfortable with it. (that's how I learned it) I was fortunate enough; when shutting down my startup a year ago and needing to land a new job, a team of coworkers I used to work with took me in without much of an interview, so I was hired into a React shop even with zero React experience. I can imagine the predicament when you have no React experience, and also can't get a React job to learn it.
spapas82 8y ago
I've written a react and a react-redux tutorial that, although are a little old, I believe that teach most important topics: https://spapas.github.io/2015/06/05/comprehensive-react-flux-tutorial/ https://spapas.github.io/2015/06/05/comprehensive-react-flux... and https://spapas.github.io/2016/03/02/react-redux-tutorial/ https://spapas.github.io/2016/03/02/react-redux-tutorial/
tomc1985 8y ago
I learned React before all these unnecessary addons and it was still borderline terrible. JSX and its school of thought is a horrible, horrible mistake and having to learn to use slightly-different names for everything (className vs class, etc) was infuriating. Still, everything one needed for an SPA was there. With thoughtful design one didn't need any of those addons. Then, suddenly, Flux comes out and it seems like a few months later the whole scene says React+Flux is the only way to go. (I personally found Flux confusing as fuck, but I didn't give it more than 15 minutes) It amuses me to see some of these JavaScript proponents get so cocky over something that only lasts a couple of months.
- brlewis 8y ago
  FTR changing class to className and for to htmlFor is not JSX, but React specifically. If you configure JSX to use a different hyperscript framework (Mithril is the one I use), then you can keep the standard HTML attributes.
antoaravinth 8y ago
With react context in place now starting from 16.3, I guess we can start using them for app level storage rather going to tools like redux.

tptacek 8y ago

So don't use Redux, React Router, and Thunks. I don't even know what React JSS is. Use create-react-app's tooling. Even Redux's author tells people Redux is overused. A pretty big percentage of the value of the flux pattern is just in having an event pubsub system, so if your application is so complicated that you really feel like you need to structure it, you can just use EventEmitter. I frankly don't understand the popularity of React Router. The core thing React Router accomplishes can be done in ~50 lines of code including the switch statement for "routes". If you like and grok React Router, use it. But I don't think it's a good idea to push through your resistance to it.

gorpomon 8y ago
I mean this in a nice way, I'd really appreciate a gist showing how you get the core concept of react-router in 50 lines. It's in a project of mine now and maybe it shouldn't be.
- mieseratte 8y ago
  Well, it really boils down to const path = findThePath(); class Router extends Component { render() { if (path === "/about") return <About /> else if (path.match(someRegex)) { const data = parseSomePath(path); return <Page { ...data } /> } else { return <Default /> } } } Seems as though React Router has gotten a bit complex because it's abstracted away from the concept of a webpage, such that one can use it in the browser, or React Native (which can be a number of environments). Of course, I say just buck-up and learn the damn thing, it isn't that complex... earn the "Engineer" in your job title! Maybe I'm just an out-of-touch neckbeard these days?
  - danvayn 8y ago
    Just a small addendum to your post -- you shouldn't use react router for react native, you should use react-navigation for that (https://reactnavigation.org/ https://reactnavigation.org/).
    - mieseratte 8y ago
      Fair enough. I'm not particularly qualified to speak about React Native, having only done toy apps.
    - connorelsea 8y ago
      I use react-router for native and there is a react-router-native package. You "shouldn't" listen to randos on the internet when they are demanding what you use or don't use.
  - sli 8y ago
    React Router v4 is particularly difficult to get used to when compared to earlier versions. While I don't much mind it (I get it working, then I don't need to touch it anymore), it definitely took me some time to wrap my head around it. So yeah, it works good when you get it working, so yeah, the best thing to do is to just buck up and learn if it you need it. But boy does it suck getting there. All of that said, I don't understand where this view comes from that Redux is extremely confusing. It can indeed sprawl a little. Say, if you keep you containers, reducers, and actions in their own directory trees. The overall architecture didn't take me very long to grasp and start to leverage. Plenty of folks find their home in Flux or MobX instead, but I'd have to guess that a lot of the confusion is actually confusion about state containers and their uses.
icc97 8y ago
> Even Redux's author tells people Redux is overused. I believe this is the post [0] in question. [0]: https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
_hardwaregeek 8y ago
You're not wrong for beginners. They shouldn't use all or any of these tools starting out. But when you reach the point where you understand React and you start to reach the limits of React's features, i.e. inline styles isn't cutting it anymore, setState is growing too big and too complex, etc., that's when it starts to get hairy. Because continuing down the path of pure React is painful, but learning all these damn libraries is also painful. That's where a lot of people get lost imo. Not to mention the times where the codebase predates you. My first experience with React was on a codebase that was pretty horribly managed. Basically a combination of magpie developers and a total lack of understanding of React patterns. When the developers are finding and trying to integrate the next new shiny lib every other week, it becomes a nightmare for any new developers.
- JamesBarney 8y ago
  I think far more people get lost trying to learn the libraries than grow an app to a size where pure react too painful. First time I used react I hated it, because everything was done through flux, want to add a field to a form. Now you need to update 4 different files and create 8 methods. Not to mention interacting with non-react components in a react way can be super painful. It was insane. Second time I dropped all of the libraries. Only used react, and any time I needed to use a non-react component I wrapped it myself, and many times did very unreacty things like use methods to do a lot of interaction. And I loved it. Everything is so much easier. I can focus on solving the user's problems, and not my react problem. The apps weren't huge, but they weren't small either. 3 months of work for 3 devs full time.
  - ericmcer 8y ago
    I had a similar experience with Redux, every event in the app went through redux. Click button > redux event fired > redux updates state > component catches state update > button listener fires. It is a total nightmare and a horrible use of redux. That is like binding every variable and function to the window object because you have no concept of scope.
rmrfrmrf 8y ago
> The core thing React Router accomplishes can be done in ~50 lines of code including the switch statement for "routes". This is a pretty common theme for me when considering any react-* library, and I think it says a lot about how nicely React lets you abstract away behavior. As for Redux, I feel like the payoff has been worth it, especially when adding in the benefits of tooling and middleware. When I learned React for the second time, I did it with Redux out of the gate, and while it did take a while to ramp up, the upside was I was able to see immediately where bugs were occurring (React + Redux DevTools) and didn't have to grok the component lifecycle before getting some data on the page.
exclusiv 8y ago
Good points. I enjoy VueJS and AngularJS, thought I wouldn't like JSX and React but React and React Native have surprised me. However, Redux looks overblown for most use-cases and takes all the fun out of it. For some cases you can just do a singleton on your shared data component. So for handling a multi screen form it just looks like export const MultiFormState = new MultiFormData(); Then import {MultiFormState} of course... Very useful. Between that and EventEmitter as you noted you can avoid a lot of extra code in many applications and get your components working well without the bloat and mental overhead.
j-b 8y ago
Any pointers for someone in my position? I have a million LOC windows forms system that going to be ported to the web. I've reviewed React, Angular, Vue, etc. As a beginner, Vue seems the best to me, however, all of the experienced web developers I talk to recommend React. After reviewing the code and walking through tutorials it just seems like overkill and overly complex but I suppose I'm missing something. It's concerning because I need to have our team port a huge code base and am not sold on React but that's what we're starting with. The developers I talk to say Angular is too complicated and React has good component based features. Nobody has Vue experience. My gut tells me Vue would be better but if I can't find guys who actually use that and have React experience instead then it seems that's the direction to head.

forgot-my-pw 8y ago

Sometimes react ecosystem and all the dependencies feel way too much. Sometimes all I want is to use data bindings, and at those times I just ended up using Vue.

tptacek 8y ago
None of these are React dependencies.
strkek 8y ago
Same here, but in my case when I need that I usually go with Mithril.js[1]. I found it by chance and instantly liked it. It's a shame that nobody seems to know it. [1]: https://mithril.js.org/ https://mithril.js.org/
- pygy_ 8y ago
  The framework usage is still growing, though it is dwarfed in popularity even by Vue (which is ~60 as large). We do little to promote it, and hyperscript (the default view syntax, i.e. m('.foo', {...attrs}, ...children) ) is not very popular (even though I prefer it to JSX, which is also supported).

deleted 8y ago

[deleted]

a_c 8y ago

In the pursuit of React, something is added everyday. In the pursuit of enlightenment, something need to be dropped everyday. [1] In the react realm, every problem is solved by throwing another layer of complexity/abstraction/whatever you call it [1] Adapted from https://www.goodreads.com/quotes/175803-in-the-pursuit-of-knowledge-everyday-something-is-added-in https://www.goodreads.com/quotes/175803-in-the-pursuit-of-kn...

IloveHN84 8y ago
Like Java/Spring. Why do not use a more simple approach, say jQuery?
- the_new_guy_29 8y ago
  This question is so wrong on so many levels
  - klibertp 8y ago
    I have a blog. It's a set of static pages, generated offline and served via Nginx. There's nothing dynamic there and the content is perfectly readable in lynx. Once in a blue moon, I want to add a screenshot or other image to a post. Such images are of various sizes, mostly larger than the (max)width of the content. I use CSS to scale them down to fit with the text, but sometimes images displayed like that are too tiny to be legible. For a long time I handled this case by wrapping <img> with <a>, basically like this: <a href="$IMG_SRC"><img src="$IMG_SRC" alt="" /></a> It works, and I like it, but it has a couple of drawbacks, most important being that it's kind of intrusive - by clicking it, you change the current url, and when you get back, even if your browser scrolls the page correctly, you need to find the place where you stopped reading. At some point, I gave up and included a bit of JavaScript, which enlarges the image while you stay on the same page. I used some kind of fancybox derivative - a jQuery plugin. Now tell me that I should've used React.
    - ben509 8y ago
      The choice of tooling has to be dictated by actually delivering a product, even if it's open source. If JQuery met your needs at the time, and your personal preferences and experience are nonfunctional requirements, it was the right call. That doesn't mean that in the future you won't grow beyond that, but having to transition a production system to a new technology is fundamentally a good problem to have.

chubasco 8y ago

I recommend the e-book Fullstack React (https://www.fullstackreact.com/ https://www.fullstackreact.com/) (I have no relationship to these guys, other than being a customer). I have had junior engineers read it in the past to get up-to-speed and it does a great job of teaching all of those technologies together in a way that makes sense and is easy to understand.

chubasco 8y ago
Let me also add that it doesn't teach them all at once. It starts from first principles and adds on new libraries as the tutorial apps become more complex.

tootie 8y ago

I found react to be extremely intuitive and easy to learn. Redux and react-redux are horribly non-intuitive. So much boilerplate and meaningless terminology and stringly-typed objects. I avoid it.

pknopf 8y ago
Switching from Redux to Mobx dramatically decreased my mental load. It is much more straight forward.
- mephitix 8y ago
  I want to learn Mobx. I like the conceptual model (functional, immutable) of Redux though - I'm just not a fan of all the boilerplate although I understand why it is there. What's your take on things you miss from Redux now that you've switched over to Mobx?
  - pknopf 8y ago
    > functional, immutable mobx-state-tree is what you are looking for. You can model it similar to your Redux setup. It is immutable. It also has the snapshot stuff Redux has.
mieseratte 8y ago
React is just mapping data to XML, which may or may not end up as XML (React DOM vs. React Native). Throw in a component lifecycle, and you're good to go. Sure, it's not jQuery simple but for a modern SPA it's about as good as it gets. It allows you to just deal with things in terms of composed functions which is wicked elegant, and since you're almost surely thinking of your page and application hierarchically it maps to reality nice and clean. Redux makes managing global / central state reasonable, and in conjunction with the `connect()` function allows you to A) pull in needed global state and B) dispatch data to be centrally processed such that your component gets to not give a shit. It'll just update as-needed. It's dumb. Strings for types sucks (it's better with Flow, or Typescript I assume) but it is what it is... the immutability can also lead to some subtle bugs if you fuckup and mutate something, but overall I'd rather write a React app with Redux than without at this point just for ease of reasoning about the system as a whole. If you've never dealt with this type of architecture, it can be strange at first but it makes managing state / data flow much easier. [0] - https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0 https://medium.com/@dan_abramov/smart-and-dumb-components-7c...

mephitix 8y ago

>> But the point would be to start with the basics and build up an understanding of why we need these libraries. And what problems they solve and what problems they don't solve. This is exactly what the well-written official React docs do. It doesn't involve any CSS-in-JS, Redux, Thunking, Webpack, etc. 1) Start off with a basic app - build the Tic-Tac-Toe app through the official React docs 2) Build a simple React app with the official CRA (Create-React-App) tool 3) Build a more complex app 4) Keep building a more complex app, learn about routing, lifecycles, performance... N) Look into Redux if you need it --- Re. Redux: The React docs have jumping off points throughout this process to understand why setState-based state management can get difficult in large applications (prop drilling) and the problems Redux solves. Look at this excellent doc on 'Lifting State Up' (https://reactjs.org/docs/lifting-state-up.html https://reactjs.org/docs/lifting-state-up.html). This makes you go through the motions of setting up a component with setState, lifting state up, and experiencing prop drilling. Redux isn't even mentioned here. Re. Thunking: In the 'Basics' section of the Redux tutorial (https://redux.js.org/basics/actions https://redux.js.org/basics/actions), here's an excellent snippet: "Action creators can also be asynchronous and have side-effects. You can read about async actions in the advanced tutorial to learn how to handle AJAX responses and compose action creators into async control flow. Don't skip ahead to async actions until you've completed the basics tutorial, as it covers other important concepts that are prerequisite for the advanced tutorial and async actions." Re. Reselect: Again, in the Basics section, in "Usage with React" (https://redux.js.org/basics/usage-with-react https://redux.js.org/basics/usage-with-react): "These are the basics of the React Redux API, but there are a few shortcuts and power options so we encourage you to check out its documentation in detail. In case you are worried about mapStateToProps creating new objects too often, you might want to learn about computing derived data with reselect." None of these 'power options' and extra tools are talked about in depth in the Basics sections of any of these docs. They are mentioned as jumping off points and the reader is warned not to dive into them early without continuing with the tutorials/docs. This seems to be exactly what you're looking for...

_hardwaregeek 8y ago
Yeah, I guess I'm not giving the documentation enough credit here. The main issue I see is all the companies rewriting their applications in React. Because I don't think they see it as a complicated engineering decision with tradeoffs and potential issues. They see it as "we need x buzzword and y buzzword". I'd prefer that the documentation outright say "This is a BAD idea if you're just doing xyz" instead of "if you need, you can check out this". Because it's very easy for developers, especially magpie developers or younger developers to think "oh yeah, of course I need this. I need my app to be S C A L E Able". The idea behind the tutorial would be giving precise problems that are solved by the tools, while also demonstrating what can be accomplished without them. Also, is it just me or is the tic tac toe tutorial really not useful? Sure, it's a good isolated example, but it's a really contrived one as well. Something like an address book or a blog would be a lot more fitting with people's usecases.

tomduncalf 8y ago

This makes me sad as I can’t help feeling that Redux being promoted (earlier on in React’s life certainly) by the community as the de-facto way to manage state has caused a huge amount of pain for newcomers. This isn’t the fault of the Redux authors - it does what it does well, and they’ve always said it’s not intended to be used for everything - but I honestly feel (and have anecdotally observed a few times) that being introduced to the complexity of Redux completely ruins people’s first steps in React (the two are often seen as inextricably linked to newcomers). Personally I feel the community should be pushing people much more towards lighter weight solutions such as component state and MobX for when the application grows. I know Redux has theoretical advantages but in the real world I’ve always found it a large burden and would personally use MobX in preference every time (which isn’t to say MobX also doesn’t have its rough points, but it’s much more intuitive).

frandroid 8y ago
So our React site is fairly static, but as it grew we had more and more state to manage across components, and more of it trickling down; in some cases state would come from fairly high up in the structure, and have to be ingested pretty far down the component chain. So as I read the React docs, I discovered childContext, and I started using it. Some of my coworkers would stick to passing props along 2 or 3 or 4 layers down, because every time I'd point childContext to them, they'd point to the part in the docs where it says it's experimental tech and that it could be removed in the future. I'd point out that the React devs have a very sane code-breaking policy and we'd just cross that road when we'd get there. It's not like we're aggressively updating to the latest release anyway. Some other people would suggest using Redux, but would agree with me that we just didn't manage _that much_ state. (We also have a React Native app, and as we manage more state in there, we did implement Redux, though it still bothers me as a tech.) Anyway, fast forward to last month, where I read Abramov explain that Redux actually uses childContext!! So: 1) there's no way they'd just rip it out of React without warning, 2) if childContext works for you, don't worry about the complexity of Redux, just pass down state and a few state-modifying functions in childContext!
- acemarke 8y ago

godot 8y ago

I feel similar to both OP and you; especially when first learning React a year ago. I feel like the only real way to learn it is to get a job where you work with React full time, and after a few months you will finally get comfortable with it. (that's how I learned it) I was fortunate enough; when shutting down my startup a year ago and needing to land a new job, a team of coworkers I used to work with took me in without much of an interview, so I was hired into a React shop even with zero React experience. I can imagine the predicament when you have no React experience, and also can't get a React job to learn it.

spapas82 8y ago

I've written a react and a react-redux tutorial that, although are a little old, I believe that teach most important topics: https://spapas.github.io/2015/06/05/comprehensive-react-flux-tutorial/ https://spapas.github.io/2015/06/05/comprehensive-react-flux... and https://spapas.github.io/2016/03/02/react-redux-tutorial/ https://spapas.github.io/2016/03/02/react-redux-tutorial/

tomc1985 8y ago

I learned React before all these unnecessary addons and it was still borderline terrible. JSX and its school of thought is a horrible, horrible mistake and having to learn to use slightly-different names for everything (className vs class, etc) was infuriating. Still, everything one needed for an SPA was there. With thoughtful design one didn't need any of those addons. Then, suddenly, Flux comes out and it seems like a few months later the whole scene says React+Flux is the only way to go. (I personally found Flux confusing as fuck, but I didn't give it more than 15 minutes) It amuses me to see some of these JavaScript proponents get so cocky over something that only lasts a couple of months.

brlewis 8y ago
FTR changing class to className and for to htmlFor is not JSX, but React specifically. If you configure JSX to use a different hyperscript framework (Mithril is the one I use), then you can keep the standard HTML attributes.

antoaravinth 8y ago

With react context in place now starting from 16.3, I guess we can start using them for app level storage rather going to tools like redux.