tanhauhau
commented
4 years ago Looking forward to it
Closed wgao19 closed 4 years ago
tanhauhau
commented
4 years ago Looking forward to it
yangshun
commented
4 years ago All the best, Wei! I'll be watching the livestream 🤓
wgao19
commented
4 years ago thank you @yangshun!
wgao19
commented
4 years ago link to slides: https://slides.com/wgao19/messing-with-document-title-with-react-0d0313
live stream comments (I found them quite interesting so list them out here)
most likely react helmet provider is at the root most component relative to all your components, so its useEffect runs last, which replaces the document.title after u set document.title it depends on who's useEffect runs first, which depends on which component mount first
document.title is the shared mutable state
but honestly we need a better replacement for helmet. the head update part is causing perf issue for us...
Interesting, react-helmet-async does not depend on react-side-effect
(reply to the previous comment) react-helmet relies on react-side-effect, which is not thread-safe. If you are doing anything asynchronous on the server, you need Helmet to encapsulate data on a per-request basis,.
- alternatively, u can use setter function in setState
- ^ yes just about to ask about this. This should solve that problem as well right?
- setBadge(badge => ({... badge, [id]: count })). if only have 1 action, yes. more than 1 type of actions, reducer is cleaner
hmm just checked vue's
keep-livedoc, it seems the idea is to persist component's state while switching, but not to share state? CMIIWThis exact feeling when people say “Redux is simple!!!!” 😂
🤣🤣🤣🤣
I kind of agree with the decision here. hared redux reducer will be hard to remove even when no pages still need it
So, agree with this here… I also don’t think UI/page-specific state belongs to Redux…
My general guideline when I use Redux is “store in Redux what I would’ve storeed in a database”… so if some piece of state should live and die with some UI component, then I wouldn’t put it in Redux.
Umm... I'm a bit lost in this case. What's the issue we are trying to solve here?
sorry, the orders are a bit off 😅
will Suspense solve the problem?
What about using React.Suspense?
Suspense alone, no, Suspense+Concurrent Mode, yes.
Thanks!!
^ got it. Now I kind of understand we want to avoid the fallback/loading if we can get the chunk quickly
other heart warming comments :))))
👋 Thank you for the talk. It's amazing
Always love it when people dive in and check the source code to learn stuff and share the experience
Thank you all, they mean a lot to me!!!
speaker
@wgao19
intro
The React ecosystem has built a lot of libraries to to work with React. Some of them are so "standard" that we only use the way we are taught and rarely think about how they become the way they are, what problems they are tackling, how they reached their conclusions now.
Via a project I've been building for the past half a year, I've reexamined (and reinvented) a lot of the wheels out there to see how they fit our needs and whether we want to write our own. So this is an anecdotal sharing about those thought processes.
Things I hope to cover:
what is something that i couldn't comfortably build with hooks and without class components? i think many of us never thought about looking at a class of components together and have them communicate among themselves
ok this is a topic that is drawing a lot of fight over, i'm not taking a side, and i don't want to join this battle. but in this talk i will actually talk about what i find missing as i build the whole project without redux
these two are not necessarily connected, but a lot of apps are doing route-based code splitting which blurs this boundary. loader libraries normally don't tap into apps' navigation, and vice versa, so it still takes non-trivial effort to make the app's interaction right when it comes to the boundaries of component and page loading when we split the app
edits: rephrase for clearer explanation
resources