I'm not usually one to ad hominem like this, but IMO you cannot both posit to give advice on good frontend engineering and fiddle with window.onScroll.
Well, even if we were talking about how to build scalable servers (we aren't), I feel like that's some sad, judgy gatekeeping to suggest that one needs to apply those same principles to their own blog else they need to receive such condescension in the comments.
It's like saying a real engineer builds their own blog. I wouldn't waste a single second of my life doing so, and the money I'm willing to spend on it reflects that as well. It comes off as petty, to me, to judge someone on this.
For example, I'm paid $100k/year to build scalable servers, not my cheap Wordpress blog.
I disagree with that one. Reinforcing your personal blog with a CDN would be a waste of money 99% of the time. It's also backend engineering, not frontend.
Even still. I spend all day working on this stuff, I definitely can't be bothered to do even more of it when I get home, so I won't blame anyone else that doesn't.
Yeah but wouldn't it be cool if when you spin the mouse wheel it takes ten revolutions and then the page scrolls over sideways, and then you spin it another ten times and it scrolls sideways to page three, etc?
True story. I forget where, but I assume they just didn't bother to test it on anything but a Macbook trackpad.
I'm not the person you are replying to but I have strong feeling that it's the latter. The scroll event has, IMHO, outside the annoying infinite scroll circus and the hijacks, a single good use: Lazy loading of expensive resources (then one would ask why it's not paginated in the first place but well).
As long as you're throttling, there's nothing wrong with interfacing with onScroll. I use it for all sorts of things. Scroll-jacking is the real issue.
Shouldn't most of those be using Intersection Observers these days? That should avoid most of the cases where someone unintentionally breaks the user experience.
Good point: I’ve been using it with polyfills which tends to hit the same point of not using an API which encourages accidental jank but it’s no substitute for native support.
I'm laughing. I literally immediately noticed the scroll-jacking and closed the tab. I then went to the comments to see how far I'd have to dig before finding this - Glad to see it at the top.
For the OP (who I'm assuming also owns the blog since the names are the same...): For the love of god - Do not fuck with my control of the browser.
I don't want passengers in my car screwing with my mirrors. I don't want sites in my browser screwing with my input.
Can somebody think of easier way to implement tabs with current setState functionality? Everyone! It may have few more lines of code but it's gonna be clear and every react dev is gonna know what it does.
Seriously, feels like we are going in circles and each round we add another layer of complexity on top.
Also a trend I noticed and it bothers the hell out of me is the fact that all these people build todo list apps and blog about it frantically how the world is different now and easier. Maintain an app with xK+ lines of code for a year or two and then tell me about it.
Hi I can understand your point but if a post is written around a difficult example you need more time to understand it then fully understand what the functionality does.
In my case I used a todo because everyone know how to do it and you can appreciate how the use of Hooks can simplify or change your code.
Sorry to be PITA. TODO list example wasn't specifically targeted at you. I'm just frustrated because I finished a big migration just Today that was caused by uninformed internet blog posts praising specific library which mostly works only in simple examples (TODO Lists).
Thanks for spreading the knowledge, but I think beginners don't take advice as "this is an option of how things can be done" but rather as "this is how we do things and we should follow this". Maybe a paragraph saying when it makes sense to go for this pattern would help.
Specifically: `react-native-navigation` replaced with `react-navigation`.
Few issues:
- Tons of bugs (see next point)
- Bigger error/bug surface, 3 languages compared to 1.
- Poor documentation
- Stopped accepting PRs for 1.0 when they decided 2.0 is the way to go (randomly, 2.0 wasn't nearly ready)
- Closing issues without any response (bot that closes them, wtf?)
Check Twitter, Google or whatever and people will mostly say positive stuff about it how they are excited and how fun it is for their TODO List app. We tried building something more sophisticated and it's insane how many things don't work as documented.
Note: react-navigation is also pretty bad, it improved in last year, but there is nothing better in the react-native ecosystem (there used to be something but during my months of inactivity it was removed from the RN itself).
Can probably compile a list of high profile libraries that suck if anyone is interested...
Seems like there is interest, will compile and publish to HN in the next couple of weeks.
react-navigation is pretty good actually, haven't had any big issues this time. At the beginning when I first evaluated it they had breaking changes way too often, things were buggy, all in all, it wasn't ready for production. Today it feels different, but I can't write a blog post about it yet as I haven't been using it for long enough.
3.0 has some breaking changes, but hey, they are using semver correctly at least!
I'm still not sure how to get previous functionality from 2.0 (app wide background image) working in 3.0, considering that now my root component has to be provided by React-Navigation.
There can be only 1 navigator rendered at a time, but it does not have to be the root of your application. Otherwise there wouldn't be any redux, either.
People already do this, they're those "awesome-react", "awesome-redux", etc GitHub repos with the giant readmes and peppered with emojis. IMO it's kinda mean to sarcastically name them like that.
Sure react-native-navigation can be a pain but saying that the only reason to choose it is toy-project articles is a bit harsh. It's really the only choice available if you want to create a react native app with first class accessibility / native interaction.
Arguably you should pick native over RN if you care that the VoiceOver back gesture works and Picture in Picture views on iPad are positioned correctly below the navigation bar but react-native-navigation is doing a valuable and difficult thing that no one else is attempting.
Another problem with this that makes it more complicated is that the TabPanel (for example) now has two interfaces an explicit props interface, and an implicit context interface that need to be met in order for it to work
They are not using it correctly. Using any should just be a stopgap measure mostly for when you are converting a codebase to Typescript. This is just an example of someone using something because they think they should be using it.
There is no point in Typescript, as new ECMAScript specs provide most of the syntactic sugar and compile-time type checking is obviated by exactly 1 test, which people using it are writing anyway; this is not a compelling use-case for an entirely new syntax, and it needs to die, instead of contributing to the already-bloated ecosystem.
What's with the title? The title on the article is fine but the one on Hacker News is terrible. It doesn't mention anything to do with hooks and components are supposed to be composable. That's kind of the goal.
I find it ironic that Angular's dependency injection system attracted so much disdain, particularly from React advocates, then React ends up implementing a less-powerful and more verbose equivalent in its new context API.
Not to deny any and all of the points made, but getting beyond those, it would be nice to get an assessment of using the new react hooks and especially the context in this manner?
I find the whole thing of reusing components in React harder than I would hope, and I find the hook API has let me remove massive amounts of code. The context API does the same thing, so combining them in some way ...?
Hooks are an attempt to reuse stateful logic. This is a problem that React never solved well moving from mixins, to higher order components, to children as render functions, and finally to hooks (maybe!). Ideally, hooks would also fully replace eg usage of react-redux even if that isn't their stated goal (managing global state across components is not really the same thing as reusing stateful logic). In fact, I don't really care about the former at all in the case of the later.
The current hooks API is not up to the task, or even up to integrating with react-redux given constraints around the new concurrent rendering and reasonable performance [1]. Hooks run during render with no ability to bail, while react-redux requires a way to avoid calling render in the first place to avoid every connected component re-rendering on every state change (ie, basically the whole tree)[2]. The new context API is also not ready for the limelight [3].
Hooks would solve some problems but at the expense of introducing yet another way to do some things. They can't replace react-redux or even provider a cleaner binding. Using hooks is risky because the API really ought to change to make them more useful, and they aren't particularly performant or powerful.
When the context API was released I began to rip out redux. After things went well with that, I no longer use redux, and I was a big fan of redux. A problems I had with using context was what seemed to me like a crufty way to access it - the whole wrapping things in a Provider. Now, I can just rip out more code and use the context hook. I'm a big fan of technologies that let you rip out tons of code. My experienc e then is that hooks are a great improvement. So far ....
62 comments
[ 2.7 ms ] story [ 70.6 ms ] threadIt's like saying a real engineer builds their own blog. I wouldn't waste a single second of my life doing so, and the money I'm willing to spend on it reflects that as well. It comes off as petty, to me, to judge someone on this.
For example, I'm paid $100k/year to build scalable servers, not my cheap Wordpress blog.
True story. I forget where, but I assume they just didn't bother to test it on anything but a Macbook trackpad.
I'm still waiting!
Which is why I hate automatic pagination unless some sort of anchor or direct URL to a section is made (prominently) available.
For the OP (who I'm assuming also owns the blog since the names are the same...): For the love of god - Do not fuck with my control of the browser.
I don't want passengers in my car screwing with my mirrors. I don't want sites in my browser screwing with my input.
https://web.archive.org/web/20190115130326/https://www.dzuri...
Seriously, feels like we are going in circles and each round we add another layer of complexity on top.
Also a trend I noticed and it bothers the hell out of me is the fact that all these people build todo list apps and blog about it frantically how the world is different now and easier. Maintain an app with xK+ lines of code for a year or two and then tell me about it.
Thanks for spreading the knowledge, but I think beginners don't take advice as "this is an option of how things can be done" but rather as "this is how we do things and we should follow this". Maybe a paragraph saying when it makes sense to go for this pattern would help.
Few issues:
- Tons of bugs (see next point)
- Bigger error/bug surface, 3 languages compared to 1.
- Poor documentation
- Stopped accepting PRs for 1.0 when they decided 2.0 is the way to go (randomly, 2.0 wasn't nearly ready)
- Closing issues without any response (bot that closes them, wtf?)
Check Twitter, Google or whatever and people will mostly say positive stuff about it how they are excited and how fun it is for their TODO List app. We tried building something more sophisticated and it's insane how many things don't work as documented.
Note: react-navigation is also pretty bad, it improved in last year, but there is nothing better in the react-native ecosystem (there used to be something but during my months of inactivity it was removed from the RN itself).
Can probably compile a list of high profile libraries that suck if anyone is interested...
Please do!
I agree with your stance on react-native navigation, but I'm not having too many problems with react-navigation. What's your issue with it?
react-navigation is pretty good actually, haven't had any big issues this time. At the beginning when I first evaluated it they had breaking changes way too often, things were buggy, all in all, it wasn't ready for production. Today it feels different, but I can't write a blog post about it yet as I haven't been using it for long enough.
I'm still not sure how to get previous functionality from 2.0 (app wide background image) working in 3.0, considering that now my root component has to be provided by React-Navigation.
<ImageBackground> <RootNavigator/> </ImageBackground>
There can be only 1 navigator rendered at a time, but it does not have to be the root of your application. Otherwise there wouldn't be any redux, either.
Arguably you should pick native over RN if you care that the VoiceOver back gesture works and Picture in Picture views on iPad are positioned correctly below the navigation bar but react-native-navigation is doing a valuable and difficult thing that no one else is attempting.
>1 test
per code path?
I’m pretty sure this is an indefensible argument
I find the whole thing of reusing components in React harder than I would hope, and I find the hook API has let me remove massive amounts of code. The context API does the same thing, so combining them in some way ...?
The current hooks API is not up to the task, or even up to integrating with react-redux given constraints around the new concurrent rendering and reasonable performance [1]. Hooks run during render with no ability to bail, while react-redux requires a way to avoid calling render in the first place to avoid every connected component re-rendering on every state change (ie, basically the whole tree)[2]. The new context API is also not ready for the limelight [3].
Hooks would solve some problems but at the expense of introducing yet another way to do some things. They can't replace react-redux or even provider a cleaner binding. Using hooks is risky because the API really ought to change to make them more useful, and they aren't particularly performant or powerful.
1. https://github.com/facebook/react/issues/14110#issuecomment-... 2. https://github.com/facebook/react/issues/14110#issuecomment-... 3. https://github.com/facebook/react/issues/14110#issuecomment-...
https://docs.cxjs.io/charts/line-graphs