9 ms·
React Router 2.0.0
- dominotw 11y agoI skeptical of benefits of declarative routing. My project got much simpler after I got rid of react-router.
- crossman 11y agoI'm curious to hear about what gains you saw from dropping it and how you handled rendering
- albemuth 11y agoIt's a single component app and state does not change at all, in fact, we should be skeptical of React too, terrible for static HTML.
- rco8786 11y agoYes, why would anyone ever use react for static html? That's not a reason to be skeptical. That's just picking the wrong tool for the job.
- sotojuan 11y agoMaybe because it's not made for static HTML? Why not just use a templating language?
- paulddraper 11y agoWell React is a templating language. I assume you mean client-side templating.
- clessg 11y agoNo offense, but I see from some of your comments here that you don't understand what React is or why it's different from what came before.
- paulddraper 11y agoSorry for my ignorance, but could you help me by explaining why my comment was wrong? This was in response to > Why not just use a templating language? React is a templating language...or maybe more specifically has a templating language, JSX. You can even run it server side. http://reactjs.net/guides/server-side-rendering.html http://reactjs.net/guides/server-side-rendering.html The problem isn't using React in that situation per se but just that server side templating (React or not) would be a better choice. I assume that's what the commenter meant.
- deleted 11y ago[deleted]
- onewaystreet 11y ago> we should be skeptical of React too, terrible for static HTML It's easy when you use webpack and a static renderer: https://github.com/markdalgleish/static-site-generator-webpack-plugin https://github.com/markdalgleish/static-site-generator-webpa...
- albemuth 11y agoFor the downvoters, this is satire... I'm not the same poster that was 'skeptical' of react router. I have used both libraries and think they're great at what they're intended for.
- lomnakkus 11y agoCould you offer more details? Why are you skeptical? What did you observe to come to this conclusion, &c?
- Bahamut 11y agoI'm skeptical of this as well, and while I had no problems with react-router on a side project, I have misgivings with the router being coupled to JSX - IMO, this is an unnecessary coupling of what should be service logic to components.
- acjohnson55 11y agoIt's not necessary at all to use JSX to describe your route configuration. Just use POJOs instead.
- deleted 11y ago[deleted]
- tlrobinson 11y agohttps://github.com/about https://github.com/about
- deleted 11y ago[deleted]
- rubiquity 11y agoOh, poor you. How dare someone else's work done freely for you not comply to a fairy tale standard like SemVer. This world is so cruel sometimes. Isn't it?
- deleted 11y ago[deleted]
- lopatin 11y agoCould you elaborate, for a layman, on why their decision to make 2.x backwards compatible with 1.x doesn't follow semantic versioning rules?
- deleted 11y ago[deleted]
- lopatin 11y agoGot it, thanks. Would it have been easier for you as a dev if they made this a minor version bump rather than a major version? Given that the code and documentation changes would have been the same.
- lopatin 11y agoIt looks like all the comments by VeilEm are deleted now, which is unfortunate. No matter how controversial or indelicately phrased, you expressed frustrations with an open source project that no doubt also have and I think you should stand by what you said.
- sehr 11y agoEdit: downvote away. react-router is bad for your code. This is against the hacker news guidelines for what it's worth, it just makes users more likely to downvote you.
- n0us 11y agoReact Router works well enough but I've had a lot of problems using it. One issue in particular I've had with this project is that they change the API so frequently that it's often difficult or nigh impossible to find documentation on issues, how to do X, or access property Y. There are the official docs, but sections have been scant or incomplete, and in some cases wrong. Crucial information might be omitted or only found in another location. Reading other people's projects or old issues is a pain because there is example of using API "X" but now it is named "Y" and does exactly the same thing so you have to go look up the release notes to even find out if the issue is relevant to you. My project broke the other day because when you provide multiple child components it used to create an object that was "this.props.children.component1" but now it just does "this.props.component1". But when you only pass one component it is still named "this.props.children" in spite of there only being one component. I was unable to find any convincing reasoning for making this change. Does exactly the same thing. Makes the interface less sensible in my opinion. Caused me to do unnecessary work to achieve exactly the same result. I get that changes are necessary when they change functionality but a lot of times it seems things have just changed with no reasoning other than just changing for the sake of changing. Maybe I'm being unreasonable and overly picky but I wish they would just keep the API stable and make the changes behind the scenes.
- cortesi 11y agoThis matches my experience with react-router. I use it in a few side projects, and I have the feeling that there's been a lot of "design-thrash" - every new release seems to bring a new interface and new ways of doing things, without much real benefit.
- arrakeen 11y agoafter banging my head against react-router for a side-project the past couple of weeks, reading that one of their motivations for 2.0 was to clean up the interaction between history and router was a sigh of relief. looking at the docs, however, made it clear that they are doubling down on their strange and confusing history API: import { useRouterHistory, hashHistory } from 'react-router' // useRouterHistory creates a composable higher-order function const appHistory = useRouterHistory(hashHistory)({ queryKey: false }) <Router history={appHistory}/> if i wanted to change the scroll behavior of router, then i'd have to do something like this: import useScroll from 'scroll-behavior/lib/useStandardScroll' const appHistory = useScroll(useRouterHistory(hashHistory))({ queryKey: false }) how does this make using router/history any clearer? i LIKE react-router, i think it's pretty damn good, but I just don't understand the rationale for their API choices. combine that with the velocity at which they're changing the APIs, it makes me wish that they'd just take their time with the design
- taion 11y agoYour code example is actually wrong. The intended API use looks like: import { Router, browserHistory } from 'react-router'; const router = <Router history={browserHistory} />; One perk is that you can then navigate using the singleton if you want, e.g. with browserHistory.push('/foo'); The scroll behavior stuff is definitely messy; I haven't had time to clean it up. The nice thing about OSS, though, is that the rest of you are all free to contribute changes.
- roblabla 11y agoI'm personally averse to the whole singleton thing. What about server side rendering? You don't want the history to be shared across requests. Most projects already have their own ways to pass dependencies (through DI or whatnot), and I can't help but feel like providing those singletons is going to end up messy.
- timdorr 11y agoWe export createMemoryHistory instead of a singleton for the server. If you don't like the singletons on the browser side, you can use the useRouter enhancer to pop in any history creation function you'd like.
- linkmotif 11y agoThere are aspects of React Router that are annoying, but I am glad not to be writing code for matching routes. Works for me. Also a fan of https://github.com/relay-tools/react-router-relay https://github.com/relay-tools/react-router-relay, because Relay is great.
- taion 11y agoWhat do you find annoying about React Router? If anything, working on react-router-relay has only made me appreciate React Router's design more. A lot of the changes in 2.x are specifically from lessons we've learned in building react-router-relay and other integrations, but they're closer to refactorings and code reorganization than to wholesale rewrites.
- linkmotif 11y agoGenerally what many others have said: that the API has changed a lot. Specifically I didn't like it when named routes were removed. But hey—it's open source. Sometimes I get worked up about this or that, but then I remember that all of this I'm getting for free and I must be grateful.
- druska 11y agoYou made it seem like this is released. Right now the official version is v2.0.0-rc4.
- paulddraper 11y agoReact: reinventing Angular one step at a time. And in more repos. https://facebook.github.io/react/docs/two-way-binding-helpers.html https://facebook.github.io/react/docs/two-way-binding-helper...
- ebola1717 11y agoReact as just a view layer is amazing, but I agree that Flux/Redux + React Router etc. feel like they're reinventing Angular. The two-way binding is definitely a feature that needs to be used cautiously. I'm not using it in my current project, but it would remove so much boilerplate for us, when it comes to forms. I would only use it for complex controlled forms, never to control application state.
- cnp 11y agoRedux / Flux / React Router have absolutely nothing in common with Angular. It might benefit you to look into each of these things with some attention because they are vastly simpler once understood.
- mambodog 11y agoThe two way binding helpers are just there for people who want to try React without giving up two way binding (eg. people coming from Angular). They are not the recommended way of doing things, and that page says as much.
- paulddraper 11y agoThe documentation seems to be the other way around: it discourages ReactLink for React newbies, not power users. > If you're new to the framework, note that ReactLink is not needed for most applications
- mambodog 11y agoThey're trying to direct newbies away from mistakenly thinking ReactLink is the 'right way'. Seems to only exist so people coming from two way data binding centric frameworks won't immediately discard React out of hand because it 'can't do two way data binding', before they get to know the framework's ideas and realise that two way data binding is usually a bad idea anyway; a notion which is fairly central to React's design. As an experienced React dev, I've never seen ReactLink in real-world use. See the docs page called Thinking in React [1] and grep through all the mentions of 'data flow' and you'll see how one way (circular) data flow is how React is intended to be used. [1] https://facebook.github.io/react/docs/thinking-in-react.html https://facebook.github.io/react/docs/thinking-in-react.html
- nanoojaboo 11y agofirst commit was Date: Fri May 9 11:18:08 2014 -0600, this is very fast to 2.0
- cheapsteak 11y ago1.0 was released in _November_, it's not even been two months. This is quite discouraging
- deleted 11y ago[deleted]
- taion 11y agoThe community consensus is that deprecation warnings don't strictly require major version bumps. That said, the React Router 2.x release does also include a few actual breaking changes to APIs that were only used by integrations - which is to say that 2.x is a minor release for end users, but is a major release from the perspective of maintainers of packages like react-router-relay or redux-simple-router.
- mambodog 11y agoOn the other hand, the team seem committed to making upgrading easy, with automated codemods for breaking API changes where possible.
- cheapsteak 11y agoWhile that is commendable, I do worry if that would actually encourage more breaking changes as they'll just need to update the codemods.
- timdorr 11y agoNode has been upgrading quickly too. Counting io.js: 4.0.0 -> 5.0.0 - 7 weeks 3.0.0 -> 4.0.0 - 5 weeks 2.0.0 -> 3.0.0 - 3 months Semver will do that :)
- cheapsteak 11y agoApologies, I missed perhaps the most important sentence > It's hard to imagine the top-level API changing much after this. Very glad to hear that and hope it will indeed become stable after this
- deleted 11y ago[deleted]
- biscarch 11y agoReact Router has been iterating towards better APIs for advanced use cases (server-side rendering, code splitting, relay (and other lib) integration, etc). Having used it in projects spanning the above use cases, the evolution of the API has been welcome change. I'm also happy to see codemods and other AST manipulations (such as babel plugins) gaining popularity. Similar to eslint's --fix, codemods are making repetitive changes easier across large codebases.
- shabbaa 11y agoI'm glad to see this thread and some debate about react router and it's features and ways it could be better. Too often any react critisism is attacked almost fanatically.
- tbrock 11y agoI think it may be time for the community or Facebook to write something that replaces react-router. It has been extremely difficult to build something on top of it and keep current. Pre-1.0 I can understand the API thrash but 1.0->2.0 in a couple months? Facebook should carry the torch here and write a standard router. This is a core component critical to the success of React for any applications more complicated than a dashboard.
- insin 11y agoI don't undestand this expectation, there's nothing magic about 1.0. They thought they had the API figured out for various use cases beyond the core routing functionality, but it turns out they didn't. In addition, 2.0 is supposed to be backwards-compatible for end users and they're providing codemods to help you update when it's convenient to do so.