React create composable components | Hacker News Reader

React create composable components

dzurico.com

59 pointsdzurico59 comments

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.

Or not being able to handle being slashdotted/hackernews-ed.

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.

Cloudflare has a free tier.

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.

Just host it on GitHub with your own domain. It's free, robust, and it means you can change the hosting if you ever want to.

Reimplementing basic browser functions (poorly) in Javascript is one of the most annoying trends in web dev.

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.

You wouldn't believe what screen transitions they made in the times of Flash.

Sure they were terrible, but at least we had auto-playing music to keep us company while we waited

Now we have both auto-playing music and video. Even on mobile!

I'll never forget zombo.com.

I'm still waiting!

Are you against listening to the onScroll event in general, or only against scroll hijacking?

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).

It's more convenient than pagination for the user. At least up until they want to share a specific section

> At least up until they want to share a specific section

Which is why I hate automatic pagination unless some sort of anchor or direct URL to a section is made (prominently) available.

I simply find it offputting for anyone to say "I as a web designer know better than you and will smooth your scrolling for you".

So, the latter then.

I guess. Why would I object to the first? As long as it doesn't impact me, you can listen to whatever the hell you want.

/thread

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.

Yes, and another bonus is that Intersection Observer is asynchronous and eliminates the need to tack on an additional debounce function.

Not yet, but soon: https://caniuse.com/#feat=intersectionobserver

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 am looking forward to switching over. Currently, I try to pool callbacks onto the same onScroll event when I can but it's still janky.

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.

Out of curiosity, which library are you referring to?

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...

>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?

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.

You can wrap your root navigator!

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.

Ah ok, the docs didn't make it 100% clear and I got tired messing with the toy app I was using with React Navigation.

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.

nothing involving redux is ever awesome

Hi, I'm a Redux maintainer. Any particular concerns I can help with?

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

What's the point of using Typescript if everything is typed as any or provides no types at all (as demonstrated in the article)?

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.

>compile-time type checking is obviated by exactly 1 test

>1 test

per code path?

> compile-time type checking is obviated by exactly 1 test

I’m pretty sure this is an indefensible argument

Wayback machine link:

https://web.archive.org/web/20190115130326/https://www.dzuri...

whatever happened to the current article?

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.

My click got hijacked and it took me to a PDF reader app on Google Play. Usually you wouldn't expect this kind of behaviour on a personal blog.

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.

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-...

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 ....

CxJS uses the same concept for charts, form validation, and other inter-component communication.

https://docs.cxjs.io/charts/line-graphs

Mirror: http://archive.fo/dM5mR

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.

I'm sorry guys can I know what's going on I really dont' understand

Reply on news.ycombinator.com