TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Why I Don't Use React Router

122 点作者 jkkramer超过 8 年前

17 条评论

WhitneyLand超过 8 年前
Justin I think you are conflating a couple issues here:<p><pre><code> 1). OSS critiques should be more polite 2). People are stupid for not doing due diligence </code></pre> First, I agree criticism should be constructive. Yet there is nothing wrong with 100 people saying here they don&#x27;t like React Router and in fact such feedback is crucial for the authors and the community. Maybe you agree; but ironically the tone of your post seemed have a bit of the scorn and derision that you are asking people to avoid.<p>Secondly, it&#x27;s already obvious people are responsible for their own projects. The motivation for stating the obvious seems to be to emphasize people should seek to blame themselves before criticizing others. Wrong. These things are orthogonal - Regardless of one&#x27;s due diligence, it&#x27;s perfectly acceptable, indeed beneficial, to critique OSS, when done in a productive way.
评论 #12518678 未加载
tptee超过 8 年前
If you&#x27;re looking to jump ship and your projects use Redux, you might find <a href="https:&#x2F;&#x2F;github.com&#x2F;FormidableLabs&#x2F;redux-little-router" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;FormidableLabs&#x2F;redux-little-router</a> to be a nice alternative. RRv4 still hoards URL state within a component, while Little Router just puts it in the store. This makes deriving most of your app from URL state a reality.<p>Check out <a href="https:&#x2F;&#x2F;formidable.com&#x2F;blog&#x2F;2016&#x2F;07&#x2F;11&#x2F;let-the-url-do-the-talking-part-1-the-pain-of-react-router-in-redux&#x2F;" rel="nofollow">https:&#x2F;&#x2F;formidable.com&#x2F;blog&#x2F;2016&#x2F;07&#x2F;11&#x2F;let-the-url-do-the-ta...</a> for more on how we differentiate from the RR philosophy.
评论 #12525731 未加载
brian-armstrong超过 8 年前
It&#x27;s great to someone express this point. Though it&#x27;s hard to beat the convenience of dropping someone else&#x27;s library into your codebase, each new dependency adds more security surface area and bloat to your application. I wish people considered this balance more carefully.<p>In general I think a littlw NIH is a good thing. Even if there exists a library that does what you want, it might also include much more that you don&#x27;t need, and perhaps the kernel of what you want fits into a small function you can write and vet yourself.
评论 #12518186 未加载
评论 #12518505 未加载
SwellJoe超过 8 年前
I recently started working seriously with node.js (I&#x27;ve tinkered over the years since it was launched, and we provide some support for it in our products, but never actually built anything with it). I went looking for a library to deal with logins, authentication, password resets, etc. Normal stuff that most web frameworks have some solutions for.<p>I found a package on npm that sounded like it did everything I wanted (plus a few extra things, but I figured I could ignore those). It took longer than I expected to install...so, I did a little digging. It had installed over 53,000 files, and the resulting directory was 110 MB in size!<p>I was absolutely flabbergasted. I couldn&#x27;t believe installing one package, for something seemingly simple, could balloon up that large. I won&#x27;t name names, as I did a little more poking around, and realized that <i>most</i> npm installations pull in thousands of files via automatic dependency resolution, though this one was a particularly egregious example. I&#x27;ve gotten to where I only install stuff via npm when I&#x27;m on a free connection; I normally work on mobile broadband, which is very expensive (and adds up to almost $300&#x2F;month even before I started playing with npm).<p>Now, to be fair, it was pulling in a web framework...maybe Express or Hapi, I don&#x27;t remember which, and all of <i>its</i> dependencies, so it was actually a lot more than just the login module. The kind of annoying bit was I already had a global installation of both of those frameworks from following tutorials, but it still seemed to insist on pulling in its own preferred versions of stuff, and putting them into the project directory.<p>I come from the Perl world, where if you don&#x27;t spend at least half your time looking for and evaluating libraries <i>before</i> you start writing code, you&#x27;re not being very productive. I&#x27;m, frankly, overwhelmed by how big and unfiltered the npm ecosystem is. I&#x27;ve found myself relieved to start tinkering with more &quot;all in one&quot; libraries and frameworks, because I don&#x27;t have the time or knowledge to evaluate libs on my own. I ordinarily prefer a more a la carte approach, where you just pull in what you need, and so big libraries and frameworks don&#x27;t fit that. But, I can&#x27;t make sense out of the ecosystem without some guidance. There are over 70,000 npm packages! Curation really has turned out to be one of the big problems in computer science.
评论 #12518656 未加载
评论 #12518477 未加载
ianamartin超过 8 年前
I really need to get my blog up and running so that I can write about things like this.<p>My view is that dependencies are someone else&#x27;s solution to my problem of technical debt.<p>I&#x27;d be a straight-up liar if I claimed to be proud of every line of code I&#x27;ve written, either for an employer or for myself. Sometimes you just have to hammer a square peg into a round hole and be done with it because deadlines. Or lazy. Or boredom. Or whatever this project is going nowhere anyway, so wtf? Hack the shit out of it.<p>I always tell myself I&#x27;m going to get back to that later and clean it up, but I often don&#x27;t because, well, moar deadlines.<p>Dependency updates--particularly breaking ones--are things I love to hear about. Dependency updates give me an excuse, both professionally and for my side projects, to revisit stuff that I knew was janky and crappy and broke when I wrote it, but have since come to accept.<p>Security updates are absolute gold in this game of not wanting to suck but still having to meet deadlines.<p>&quot;Sorry boss, but there&#x27;s a vulnerability in lib x. We have to update. But it&#x27;s breaking. So now we have to refactor. Two weeks, at least. Maybe more.&quot;<p>I just got rid of a crap-ton of bad code while I was updating for that dependency. Oops.
评论 #12519344 未加载
评论 #12519921 未加载
评论 #12519967 未加载
n0us超过 8 年前
As the person who wrote the top comment in the thread that you link to, I will admit: You are right for the most part. The choice to use an unproven library is my fault as it was my choice and it is also my responsibility to deal with the consequences and costs of the instability. This is why I will be removing React Router from my project as soon as I can find a stable and suitable replacement.<p>Recognizing the responsibility for your own actions does not preclude you from being frustrated and at times outright angry at the outcomes of those actions. In this case I (wrongly) assumed that after a 1.0 release the library would be relatively stable and have been repeatedly duped into believing that this time the major version release would be the stable one. I don&#x27;t really see anywhere that people were issuing an outcry for V4, so I am still confused as to why it was so urgent to release it. It wasn&#x27;t perfect but it was fine. Unfortunately in my frustration and confusion I chose to write a very strongly worded comment that apparently some people did not like.<p>&gt; To be clear: developers that release libraries and then iterate the API in public do not deserve personal scorn for doing so<p>I have never gotten the impression that react-router was someone&#x27;s personal library, rather it is a community project that is maintained by notable members of the javascript community and it is my belief that delivering half-baked stuff to the people who counted on them, and who they led to believe could count on them, is not a fair thing to do. I don&#x27;t believe it is unreasonable to be frustrated with fickle leadership from people who stepped up to lead the project. If they can&#x27;t deal with the criticism or don&#x27;t have the time&#x2F;effort&#x2F;inclination&#x2F;whatever to lead in a way that is agreeable to most of the community then perhaps someone else could lead. When projects have thousands of stars on github, making rapid successions of breaking changes throws all of those people for a loop.<p>If you do in fact view the repo as your personal project and want to make huge changes all the time, like every 6 months, I don&#x27;t think that the version with thousands of stars is really the place to do that. Why not just do it on your own where it isn&#x27;t going to affect so many people.<p>Note: Neither this, nor my original comment should be taken as personal attacks on the maintainers although I am aware that both are probably over stated. I&#x27;m sure they are all extremely talented developers and kind people.
评论 #12518554 未加载
jhgg超过 8 年前
We use React Router on our project. Looks like 4.0 does break pretty much everything.<p>My thoughts on the upgrade are pretty much:<p>- Do we actually need to upgrade? Old react router works fine.<p>- If we do need to upgrade - how long will it take? If it&#x27;s just a few hours to shift some code around, maybe it&#x27;s not that bad. Especially if it&#x27;s moving to a cleaner more &quot;react&quot; API.<p>At the end of the day, we could write our own routing class, or another. We&#x27;ll probably stick with react-router though - but save the upgrade for a day where we&#x27;ve got nothing else to do, or if an engineer has some free time.
评论 #12518295 未加载
lstamour超过 8 年前
I&#x27;m reminded of <a href="https:&#x2F;&#x2F;medium.freecodecamp.com&#x2F;you-might-not-need-react-router-38673620f3d#.6i54dhtjb" rel="nofollow">https:&#x2F;&#x2F;medium.freecodecamp.com&#x2F;you-might-not-need-react-rou...</a> which discusses how to write your own such functionality from scratch. I often find that before adopting third party code you really have to consider it and perhaps even leave it out and feel the pain before accepting that it&#x27;s necessary and adopting it. And even once you do, you should be open to maintaining or replacing it. There&#x27;s a cost to roll-your-own though, you might need to write additional documentation. For routing though, it&#x27;s usually one function and easy enough to grok on its own.
linkmotif超过 8 年前
Don&#x27;t get it. It&#x27;s FOSS. npm install the version you want. A new version released you don&#x27;t like? Keep using the old version. Don&#x27;t like the old version? Write your own. Fork it. It&#x27;s free and awesome global collaboration!
diggan超过 8 年前
I might be missing something (after reading the article twice) but the author says nothing about why he doesn&#x27;t use React Router...<p>The only mention I can find is &quot;But the API smelled funny to me, and had not settled, so I continued to wait&quot; that hints that the API is changing and looks weird. But other than that, there is no constructive criticism here.<p>I&#x27;m all for being able to write freely about software we find bad, but without any concrete examples or even pointers to what is bad, I don&#x27;t think this article have any merit (except that it&#x27;s good to make sure you understand the dependencies you have).
评论 #12520244 未加载
jameslk超过 8 年前
If anyone is wondering what leads to a Not Invented Here mindset, this probably would be a good example of it. Sure, it&#x27;s not the fault of the open source library author that you depended on their work. However, when OSS fails to deliver or we criticize others for counting on it, we only discourage the dependability of OSS and push others away from the community. If we care about the continued adoption and growth of OSS then we&#x27;ll need to have higher standards as well.
cle超过 8 年前
This is a very important dimension to consider when making technical decisions. I&#x27;ve never been able to find an easy way to assess this risk, beyond hearsay and word-of-mouth.<p>Is anyone aware of an easier way to assess these longer-term risks of a piece of technology? Things like API stability, community strength and responsiveness, backwards compatibility, upgrade paths, etc.
评论 #12518416 未加载
评论 #12518307 未加载
wesleytodd超过 8 年前
Yep, this is a thing I push with my team all the time. Always vet your deps. In the long run is is WAY worth it. In the short run the cost is rather minimal unless you have devs that cannot actually deliver on the needs the dependency covers.
评论 #12520827 未加载
dustingetz超过 8 年前
I just wanted to say that the clojure ecosystem is littered with the carcases of half baked libraries. Including some of my own. Its not a JS problem, its the beauty of open source &amp; low friction sharing.
评论 #12518997 未加载
TheAceOfHearts超过 8 年前
I generally agree. I&#x27;ve been using RR for a while, and I&#x27;m not the biggest fan of their APIs. Nothing wrong with it, it just doesn&#x27;t do what I want it to do; or rather... It does too much stuff, most of which I don&#x27;t use. Just my opinion.<p>With that being said, they claim you&#x27;ll be able to migrate slowly to v4, so hopefully it&#x27;s not so bad. If they just broke backwards compatibility without a migration strategy, I&#x27;d certainly feel much more frustrated. I went with RR largely because it&#x27;s widely used. I also don&#x27;t think it&#x27;s an unreasonable expectation for a widely used library to provide a migration strategy. Not that they&#x27;re under any obligation to do so, of course.<p>My personal bar for adding dependencies is asking myself: would I feel comfortable debugging and fixing this? I recognize that it&#x27;s not a free ride.
snippet22超过 8 年前
That&#x27;s why they call it angular 2. It&#x27;s finally out and ready to be used. Works really well with routers. Although you don&#x27;t get the constant updating but you do get codeless directives that are really easy to understand.
oceanswave超过 8 年前
Every ecosystem is full of &quot;half-baked&quot; libraries. JS has more as the ecosystem is bigger and the barrier to entry is very low. It&#x27;s the nature of open source, it&#x27;s also the nature of open source to evaluate dependencies.