4 ms·

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 t

by 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.

mieseratte 8y ago
Partly, the fact that React-Router has upgraded so many times in divergent ways in a short amount of time has left many folks with a bad taste in their mouth. If the router was just "Buck up, learn it, and you're golden" I suspect we wouldn't hear too much hollering about it. Unfortunately, the hassle of using it is so close to clockwork I feel like I should just schedule a week every six months or so for maintenance.
- tptacek 8y ago
  What's the win to keeping up with it? Am I wrong that the problem it's solving is really pretty simple? I had the same problem with react-bootstrap, which I used for about a year and ran into regular upgrade compat problems. I wouldn't mind that much except that wrapping a React component around a fragment of HTML is not a problem so difficult that I'd endure compat problems in a dep to solve it.
  - mieseratte 8y ago
    > What's the win to keeping up with it? With the router, it was never a matter of us just deciding to upgrade for the sake of upgrading but rather ending up being painted in a corner with peer dependencies requiring upgrade. Additionally, because we were a micro service / many SPA outfit, we ended up with a dozen or more applications at varying levels of libraries so you had to deal with 2.x, 3.x, and 4.x or just upgrade. For those of you reading along thinking "This sounds like a dysfunctional environment!" You're right! Imagine having five heads of department, albeit two interim, in a year. > I had the same problem with react-bootstrap, which I used for about a year and ran into regular upgrade compat problems. I'm in the middle of building out an internal component library based on `react-bootstrap`, so that's fun to hear... Have your issues mostly been upgrades of the library? Or of Bootstrap versions? We internally decided we're just sticking with Bootstrap 3 for the foreseeable future with the hope that it will mean we don't have many issues to deal with.
    - tptacek 8y ago
      It's been a long time since I used react-bootstrap. I just stopped using it and wrapped the Bootstrap HTML myself. I wouldn't be surprised if it had settled down. It's possible react-router has settled down too, but the experience I had of "I can't believe I ever wasted time trying to figure out react-router" after implementing a "router" myself was so powerful that I'm pretty averse to finding out.
Izkata 8y ago
> Say, if you keep you containers, reducers, and actions in their own directory trees. That layout is the biggest reason it took me so long to understand it when my team brought it in. It goes a bit against the spirit of Redux, but the tutorials really should pair up action and reducer in the same directory, then later explain why the other way is also useful. We currently do this: state/ |---some_piece_of_state/ | |------reducer.js | |------actions.js | |------tests.js | |---another_piece_of_state/ |------reducer.js |------actions.js |------tests.js It ended up way, way easier to understand and get people in on it, because in the vast majority of cases we don't need multiple reducers listening to the same action.
- acemarke 8y ago
  Redux itself doesn't actually care how you organize your file structure (per the FAQ entry at https://redux.js.org/faq/code-structure https://redux.js.org/faq/code-structure ). For the size of the tutorials, it's probably simpler to use a "folder-by-type" structure. But yes, for real apps, I myself have settled on a "folder-by-feature" structure. Note that either approach is completely orthogonal to whether you have multiple reducers listening to the same action. The tutorial is already trying to explain a lot of concepts that are new to most people, so we try to keep it focused on the meaningful concepts. Throwing in side discussions on folder structures would probably add more confusion at that point in the learning curve.
  - Izkata 8y ago
    See, the part we disagree with seems to be here: > so we try to keep it focused on the meaningful concepts. For me, scattering a single feature across multiple directories makes it far harder to understand what relates to what. It's _less_ meaningful to group by type than by feature, which makes it harder to learn than it should be. I'm not saying the docs should go into asides about the alternative structures all over, but rather the people promoting Redux should definitely consider whether or not their examples smell more of spaghetti code than they need to be.

by sli 8y ago

mieseratte 8y ago

Partly, the fact that React-Router has upgraded so many times in divergent ways in a short amount of time has left many folks with a bad taste in their mouth. If the router was just "Buck up, learn it, and you're golden" I suspect we wouldn't hear too much hollering about it. Unfortunately, the hassle of using it is so close to clockwork I feel like I should just schedule a week every six months or so for maintenance.

tptacek 8y ago
What's the win to keeping up with it? Am I wrong that the problem it's solving is really pretty simple? I had the same problem with react-bootstrap, which I used for about a year and ran into regular upgrade compat problems. I wouldn't mind that much except that wrapping a React component around a fragment of HTML is not a problem so difficult that I'd endure compat problems in a dep to solve it.
- mieseratte 8y ago
  > What's the win to keeping up with it? With the router, it was never a matter of us just deciding to upgrade for the sake of upgrading but rather ending up being painted in a corner with peer dependencies requiring upgrade. Additionally, because we were a micro service / many SPA outfit, we ended up with a dozen or more applications at varying levels of libraries so you had to deal with 2.x, 3.x, and 4.x or just upgrade. For those of you reading along thinking "This sounds like a dysfunctional environment!" You're right! Imagine having five heads of department, albeit two interim, in a year. > I had the same problem with react-bootstrap, which I used for about a year and ran into regular upgrade compat problems. I'm in the middle of building out an internal component library based on `react-bootstrap`, so that's fun to hear... Have your issues mostly been upgrades of the library? Or of Bootstrap versions? We internally decided we're just sticking with Bootstrap 3 for the foreseeable future with the hope that it will mean we don't have many issues to deal with.
  - tptacek 8y ago
    It's been a long time since I used react-bootstrap. I just stopped using it and wrapped the Bootstrap HTML myself. I wouldn't be surprised if it had settled down. It's possible react-router has settled down too, but the experience I had of "I can't believe I ever wasted time trying to figure out react-router" after implementing a "router" myself was so powerful that I'm pretty averse to finding out.

Izkata 8y ago

> Say, if you keep you containers, reducers, and actions in their own directory trees. That layout is the biggest reason it took me so long to understand it when my team brought it in. It goes a bit against the spirit of Redux, but the tutorials really should pair up action and reducer in the same directory, then later explain why the other way is also useful. We currently do this: state/ |---some_piece_of_state/ | |------reducer.js | |------actions.js | |------tests.js | |---another_piece_of_state/ |------reducer.js |------actions.js |------tests.js It ended up way, way easier to understand and get people in on it, because in the vast majority of cases we don't need multiple reducers listening to the same action.

acemarke 8y ago
Redux itself doesn't actually care how you organize your file structure (per the FAQ entry at https://redux.js.org/faq/code-structure https://redux.js.org/faq/code-structure ). For the size of the tutorials, it's probably simpler to use a "folder-by-type" structure. But yes, for real apps, I myself have settled on a "folder-by-feature" structure. Note that either approach is completely orthogonal to whether you have multiple reducers listening to the same action. The tutorial is already trying to explain a lot of concepts that are new to most people, so we try to keep it focused on the meaningful concepts. Throwing in side discussions on folder structures would probably add more confusion at that point in the learning curve.
- Izkata 8y ago
  See, the part we disagree with seems to be here: > so we try to keep it focused on the meaningful concepts. For me, scattering a single feature across multiple directories makes it far harder to understand what relates to what. It's _less_ meaningful to group by type than by feature, which makes it harder to learn than it should be. I'm not saying the docs should go into asides about the alternative structures all over, but rather the people promoting Redux should definitely consider whether or not their examples smell more of spaghetti code than they need to be.