81–90 of 107 posts
The number one thing I’d like to strengthen is the process of building a react component for publishing on NPM. It’s way different from building something with create-react-app. I need a solution that has zero config, has HMR, the latest JavaScript and automatic deployment for demos on github pages. I have so many components I could publish, but just can’t be bothered to figure this out.
Not a single lesson titled: "How to write tests" With snapshots, while not perfect, they do catch a lot and are easy to do (and more importantly, easy to update when things change). React components are relatively easy to further test with enzyme and jest. Without a focus on instructing people how to do testing, people never bother.
React, with it’s declarative approach, stateless components, immutable state, etc. seems purpose-built for testability. TDD with React should be ridiculously easy, but I wouldn’t know, because no one seems to want to talk about it.
I fear that by the time I'm good enough at react, another library will come out
Eh, React is 5 years old. I've been writing it professionally for 3. I'm not worried. And honestly -- React doesn't have the same pain points jQuery/Backbone/Angular1 did where I couldn't wait to move on after 6 months. We'd have to see an absolutely massive paradigm shift before I'd regret writing my apps in React.
Earlier quoted context omitted.
The site only goes to IE10 though. The first three examples, which are probably the worst, improve greatly in more modern browsers that include the fetch() API. In my view even the jQuery examples look a lot better if you can write ES6.
The first example is not really apples to apples as it doesn't even have error handling which makes the native function look longer. Probably because getJson doesnt support errors by default and you have to use promises http://api.jquery.com/jquery.getjson/ I ran into this issue of jquery silently failing a while ago and will always remember that pain point
Earlier quoted context omitted.
The first time I saw that site, I assumed it was a joke. Seems more to me like it's trying to tell people how nice jQuery is. Who would look at that and walk away with the opinion that jQuery is unnecessary?
The idea is that if you're building your own Javascript library, you can avoid the huge dependency of jQuery. If you're developing a user-facing app, then yeah, jQuery is still pretty darn helpful.
Earlier quoted context omitted.
The idea is that if you're building your own Javascript library, you can avoid the huge dependency of jQuery. If you're developing a user-facing app, then yeah, jQuery is still pretty darn helpful.
Its 85kb. I wouldn't say its a huge dependency. I rather keep it than having to learn an entirely new framework.
Earlier quoted context omitted.
Its 85kb. I wouldn't say its a huge dependency. I rather keep it than having to learn an entirely new framework.
Are you referring to vanilla JS as an entirely new framework?
Earlier quoted context omitted.
I'm a Redux maintainer. Any particular pain points you're concerned about?
Not OP, but my day to day job is helping teams with their migration onto React (often for big sites you've used or have at least heard of). Here goes, although these probably aren't anything new to you: – As far as I understand, Redux was intentionally made to be low-level and unopinionated, with the idea that other libraries would build on top of it. That has not really borne out and it actively makes adoption extre…
FWIW, there _are_ a lot of chunks of reusable Redux-based logic out there (which I have listed in my Redux addons catalog [0]), but I'd agree that there does tend to be enough variation in people's use of Redux that sharing larger chunks can be difficult. I've seen quite a few experiments with various forms of Redux "modules", but yeah, none of them have fully taken off. There _are_ several very interesting higher-level wrappers around Redux that look like they offer potential solutions to the reuse / structure question, like Kea, Rematch, and redux-bundler.
While I sort of understand the concern in your last paragraph, I'm again not sure what sort of "guidance Redux could offer" in this case. If you've got suggestions for improving the docs, please file an issue, or even better, a PR, and we can work to get something in.
Earlier quoted context omitted.
Too late, http://youmightnotneedjquery.com/
The first time I saw that site, I assumed it was a joke. Seems more to me like it's trying to tell people how nice jQuery is. Who would look at that and walk away with the opinion that jQuery is unnecessary?
The site suggests you try not to make it a dependency if you're writing a JavaScript library. I also suggest vanilla JavaScript for simple pages that need just a smattering of interactivity.
Earlier quoted context omitted.
Not OP, but my day to day job is helping teams with their migration onto React (often for big sites you've used or have at least heard of). Here goes, although these probably aren't anything new to you: – As far as I understand, Redux was intentionally made to be low-level and unopinionated, with the idea that other libraries would build on top of it. That has not really borne out and it actively makes adoption extre…
I'll be honest and say that a lot of those concerns seem like things that Redux couldn't possibly have any solutions for. How can the core library tell you "what to name action creators" or "where to put connected components"? Those are style guide / app architecture concerns that are going to be specific to each team. FWIW, there _are_ a lot of chunks of reusable Redux-based logic out there (which I have listed in m…
Exactly, but it's Redux's fault that it actively adds like 5 new styleguide/app architecture concerns to worry about in your project! That is a bad thing about its fundamental design.
For crying out loud, just put redux-thunk back in the core library. Nobody doesn't have async actions! One less thing to make a decision about.
> While I sort of understand the concern in your last paragraph, I'm again not sure what sort of "guidance Redux could offer" in this case.
I find that response pretty obtuse. I just told you what I told my developers in their code reviews, how about some language like that? Developers don't realize that connect() is just dependency injection for props, and those props should at least make sense from a dumb-component standpoint before Redux is involved.
Or how about including a render-prop version of connect in the library, so developers don't go making a bunch of useless props in the first place? The HOC version is what is leading them towards poor design decisions.
If your library is too easy for average devs to use poorly and my biggest headache during code reviews, to me that points to some issue with the library. This is why there is often "backlash" type sentiments around Redux being so popular.