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!
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.
Which is why I hate automatic pagination unless some sort of anchor or direct URL to a section is made (prominently) available.
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.
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.
- 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...
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.
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.
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 . 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). The new context API is also not ready for the limelight .
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.