20 ms·

You might not need an effect

• yieldcrv 4y ago
  huh. well I’m lost then. glad they’re writing this up. I come to react after hooks was introduced, and have been kind of put on a pedestal for not needing to “learn hooks” since thats all I know, for React. still looks like I need to relearn something.
• aeroaero 4y ago
  This page should be mandatory reading for any dev working in react. The biggest mistake I see with devs of all levels is over use of effects. This seems to be especially bad for anyone who originally worked with class components. The mental modal shift was large and people tried to fit their understanding of lifecycle methods into hooks, attempting to replicate similar behaviour. The docs at the time did a poor job of explaining why this was a bad idea.
  • brundolf 4y ago
    100%. Effects are an escape-hatch, and it's really common for people not to treat them that way. All of the new docs are gold, but if I could only pick one to recommend that every React developer read, it would be this one
  • cjonas 4y ago
    Second is abuse of useState for calculated values
• Rapzid 4y ago
  > Effects are an escape hatch from the React paradigm Hooks are overused in general. But I really disagree with this sentiment. Its useEffect and useLayoutEffect(okay useInsertionEffect too) hooks are THE mechanism they CHOSE to expose component life cycle. It's not an escape from React paradigm, it IS the paradigm. Function component React would be useless without these hooks; the DOM is an external system! I'm really just put off by the React documentation in general. It feels like it's aimed at junior devs working on FE assembly lines and they want to keep the blinders on them. "Pay no attention to the man behind the curtain!".
  • robertoandred 4y ago
    Or maybe you shouldn’t be thinking in terms of a “component lifecycle”.
    • lloydatkinson 4y ago
      Exactly - OP is perpetuating bad explanations. https://epicreact.dev/myths-about-useeffect/#:~:text=Here%27s%20the%20crux%20of%20the%20issue%3A%20useEffect%20is,the%20dogId%20changes%2C%20fetch%20the%20new%20dog%27s%20information.%22 https://epicreact.dev/myths-about-useeffect/#:~:text=Here%27...
      • Rapzid 4y ago
        That's bullshit; useEffect is a lifecycle hook. From the documentation for the useEffect SETUP parameter: > setup: The function with your Effect’s logic. Your setup function may also optionally return a cleanup function. When your component is first added to the DOM, React will run your setup function. After every re-render with changed dependencies, React will first run the cleanup function (if you provided it) with the old values, and then run your setup function with the new values. After your component is removed from the DOM, React will run your cleanup function one last time.
        • dgb23 4y ago
          It absolutely is. But the article and the comments above mention that it’s more useful to have the mental model of synchronizing side effects with state. It’s good advice, because it addresses a major stumbling block people struggle with. After that the code and the way useEffect is used becomes simpler.
          • Rapzid 4y ago
            From the linked article in this thread: > Here's the crux of the issue: useEffect is not a lifecycle hook. That doesn't leave much room for ambiguity; seems like a definitive statement. Many don't see any nuance here and then go around blasting people for saying useEffect is a lifecycle hook because they read on some blog the exact opposite. But anyway, what is a lifecycle hook if not a way to synchronize two systems... ( ͡° ͜ʖ ͡°)
• owenpalmer 4y ago
  You might not need React
  • lloydatkinson 4y ago
    You might not need to write drivel comments too
    • zach_garwood 4y ago
      You should lead by example.
      • lloydatkinson 4y ago
        The 8 votes I appear to have on my comment demonstrate that I'm not alone in this. Pointing out pointless comments is not itself a pointless comment, but who am I to argue with an expert in drivel comments? Feel free to refer to the HN rules on comment quality.
• parasti 4y ago
  Weirdly disappointed, turns out I still need useEffect because I've been using it as intended.
  • eyelidlessness 4y ago
    You might not not need an effect.
• erwinh 4y ago
  Wait so in the prop change example they are now recommending that you can update state during a component render?
  • _thisdot 4y ago
    Far as I see they aren't. They're recommending you don't use unnecessary state. From the example, if you have state for `firstName` and `lastName`, you don't need another state for `fullName`. Just calculate it during the render as `'${firstName} ${lastName}'`
    • foota 4y ago
      They're referring to https://react.dev/learn/you-might-not-need-an-effect#adjusting-some-state-when-a-prop-changes https://react.dev/learn/you-might-not-need-an-effect#adjusti..., where they literally call setFoor in the render method. I guess this makes sense, but it's weird after all the "never do anything stateful in render"
  • foota 4y ago
    Wow, that's really weird.
  • jannes 4y ago
    Yes, and they explain it as well. Doing that leads to the component re-rendering immediately without rendering any child components. This should be faster than useEffect which only executes after the entire render has been committed to the DOM.
  • aeroaero 4y ago
    Yep it can be a useful pattern, but it must be in a conditional to stop an infinite loop. This useful guide points it out as well: https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/#setting-state-while-rendering https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...
  • deleted 4y ago
    [deleted]
• fabian2k 4y ago
  Interesting Detail about this from Dan Abramov: https://twitter.com/dan_abramov/status/1638773531881140224 https://twitter.com/dan_abramov/status/1638773531881140224 > fun fact: You Might Not Need an Effect was inspired by a little investigation. i spot-checked random 128 useEffect calls in the Meta codebase, classified them into several groups, and 59 out 128 were unnecessary. My own experience, on a much more limited scale, is similar. Especially developers new to React tend to write more useEffects than actually necessary. These often add unnecessary complexity and make the component much harder to understand.
  • albert_e 4y ago
    Sounds like this is more general pattern I recently reviewed an architecture on AWS that has 5 services chained together to make information flow from source to target. There was no justification for the middle three. The volume of data, loose coupling, native support for direct integration were all there to directly connect source to target.
  • Dextro 4y ago
    I agree with this sentiment. I find that most developers seem to be stuck in thinking of their components as imperative. They expect to alter the state (dom) directly instead of describing the dom as a function of state (props). Because of that, they quickly reach for the escape hatch that useEffect provides everytime they need to change something. I genuinely don't know how to help my fellow team members grasp the basic concept of components better. It doesn't seem, to me, like it's something everyone gets eventually. I've actually seen far too many developers who just don't seem to get there even after long months working with component libraries. As a side note: I don't get all the love for class components. All I remember from using them were the endless bugs because we somehow missed something on willUpdateProps or whatever. Class components could have worked but they always felt like the different life cycle methods were all cobbled together with little overall consistency (see Vue for an example of life cycle hooks done better, even if I have plenty of other gripes with Vue's design)
    • MrPatan 4y ago
      Indeed. React was a welcome innovation because it enabled V=f(S). That's it. The vDom was fast enough that it made re-rendering your view on every state change possible. Now you don't have to worry about rendering, you describe your components as pure functions and you're done with that side of things, now you "only" have to worry about the state of your app. Seeing comments here wondering "How am I supposed to use jQuery with React otherwise?" is baffling and disheartening.
• billllll 4y ago
  IMO if you need a long doc like this pointing out the sharp edges, then I think you've done a poor job in designing the framework. I love the terseness, reusability, and typing of React hooks, but hooks have too many weird edge cases (this article, dependency list, order of hooks, etc) versus class components, whose design was simple and elegant. I'm just an old man yelling at clouds though, the terseness of stateful components defined in a function, plus simple typing with TS (no defining proptypes) is too appealing to me personally. Maybe I'll check out Solid next time, which seems to have less weird edge cases.
  • junon 4y ago
    I've used Surplus for years and love it. Highly underrated framework. It's hooks, but designed properly, and consistently beats out almost all other frameworks performance-wise. It's in need of a few upgrades though, namely a few edge cases in the old JSX parser (it was written before Acorn had good JSX support) but works pretty much perfectly still today.
    • ihateolives 4y ago
      > It's hooks, but designed properly, and consistently beats out almost all other frameworks performance-wise. Performance is nowadays one of my last concerns with frameworks. They're all snappy enough except for corner cases. More important is whether there are standard ways of doing things vs everyone inventing their own. Our company uses Vue which has standard lifecycle methods, standard way of scoping CSS etc, officially endordsed store etc. Makes it much easier to bring people up to date when they're joining the projects.
  • bowsamic 4y ago
    Really it is quite an amazing situation. The conceptually clunky but easy to understand class components vs the conceptually pure but esoteric hooks. Even at the time the React dev team were putting in a lot of effort to say "you will get it soon, don't worry", because they already knew it was in many cases difficult to understand and use properly. That should have already been enough of a sign to not push it so hard.
  • 4y ago
• karaokeyoga 4y ago
  In many cases, we can use useMemo instead of useEffect: - the function is run immediately (during the render cycle, not after) - we can take advantage of the dependency array I think the reason this pattern isn't more popular is that we're taught to use useMemo to memoize a result, but we can also use it more simply … to run a function (during the render cycle) whenever the dependency array changes. Just call useMemo and don't assign the result to anything, such as: useMemo(myFunction, [dependency array])
  • lukax 4y ago
    useMemo is really nice for sync effects but it breaks hot reload because hot reload does not call useMemo again. E.g. you can subscribe to something using useMemo (so that it is synchronous and you can use the current subscription value in the current render) and then unsubscribe using useEffect as a cleanup callback. When the component is hot reloaded, the useEffect cleanup callback will be called but the useMemo will not be called again if the dependencies do not change. You can use useSyncExternalStore for that but you need to make sure that your subscription value is immutable or hack around it with refs.
  • Rapzid 4y ago
    This is underdiscussed IMHO. I refer to the render function calls as "the way down" and then after everything is mounted when React starts calling the useEffect callbacks "the way up". Many applications suffer from the waterfall rendering problem but even for those that don't, if they are large, they will absolutely want to kick off network calls on "the way down". You can easily add a ton of time to LCP by waiting to kick network calls off until the tree has mounted. I actually go a little out of my way to make sure as much of the tree as possible can render and mount with missing data. This way the work is occurring while data is fetching in parallel, and then a minimized number of components need to be updated once the data has arrived.
  • mrctte 4y ago
    Isn't this exactly what useLayoutEffect is for? https://react.dev/reference/react/useLayoutEffect https://react.dev/reference/react/useLayoutEffect
• deleted 4y ago
  [deleted]
• weird-eye-issue 4y ago
  Why is all of the text on this page bold?
  • rawoke083600 4y ago
    useBoldEffect() ?
    • weird-eye-issue 4y ago
      That's deprecated. It is now useStrongEffect()
  • ricardobayes 4y ago
    Heavy fonts are the new "grey font on grey background".
• the_gipsy 4y ago
  > They let you “step outside” of React and synchronize your components with some external system like a non-React widget, network, or the browser DOM. This doc is generally on point and a very important lesson to drill into the heads of people new to react, however that particular phrase is completely misleading. React is absolutely pushing you to use lifecycle effects where necessary. Calling that "stepping outside" is just dishonest. React is not a "pure view library" that you have to integrate with state management. It makes you handle the extremely impure chain of (route change, component "mounting", data fetching...), all in the rendering code.
  • branko_d 4y ago
    > route change, component "mounting", data fetching... This should really be: route change -> data fetching -> rendering After the data is fetched, it should just be assigned to a state somewhere, and the React should, well, "react" to the state change. This may seem a bit complicated for simple cases, but keeps the execution flow explicit and "steppable" though the debugger. We use MobX for the "react" part; I'm sure this is not the only way.
    • the_gipsy 4y ago
      Yes, but that is The Elm Architecture. React's docs guide you towards using react-query and react-router, making everything lifecycle bound and the renders impure. https://react.dev/reference/react/useEffect#what-are-good-alternatives-to-data-fetching-in-effects https://react.dev/reference/react/useEffect#what-are-good-al...
  • ojkelly 4y ago
    > Calling that "stepping outside" is just dishonest. I don’t think it’s dishonest. There’s two main phases in react, render and commit. Render is interruptible. For example when a new event like an interaction comes in, the in progress render might get chucked out and restarted with the new information. Commit isn’t interruptible. It’s a sync phase. This is where all the effects run, and the purpose is to take the new state from the render phase and synchronise it to the external systems. Aka cause side effects. The useEffect hook running in the commit phase, does let you step outside of the react framework. It lets you safely interact with external systems. If you tried to do any of that in the render phase, you risk getting cut off halfway, or doing things out of order. > React is not a "pure view library" that you have to integrate with state management. A view library without state management would be a templating engine right? > It makes you handle the extremely impure chain of (route change, component "mounting", data fetching...), all in the rendering code. It lets you define how to respond to those changes in the render phase, but they aren’t applied until the commit phase. And that means you can wrap up the complexity in well tested components that provide a simple API.
• larsnystrom 4y ago
  useEffect is absolutely core to doing to react development with hooks. Saying "you might not need an effect" is like saying "you might not need the + operator", like yeah, sure, if you're not trying to add two numbers or concatenate a string or whatever you won't need that operator, but in like 99.999% of all applications you will need it.
  • muspimerol 4y ago
    That's really not the point of the article. It's addressing overuse of useEffect(), not implying that you never need it.
    • larsnystrom 4y ago
      I think my gripe here is the casual use of “you might not need…”. It’s inspired by the “you might not need redux” article by Dan Abramov, but the difference here is that while you might not need Redux, you most likely will need useEffect. They’re just not same in that regard. Maybe I’m just being pedantic here, but I think how you use words matters, and in this instance a better title would be “avoid unnecessary useEffect calls” or something like that. “You might not need an effect” is just poor (sloppy?) wording, because it’s usually objectively wrong. The reason it matters in this instance is that with the current title I’m going into the article thinking I’ll learn some new way to do effects which is better than useEffect. But the article offers no alternative to useEffect. You will need useEffect.
      • andrewingram 4y ago
        In both cases (this page, and the one you mention) I think you’re inferring the wrong context — which is reasonable because it’s a legitimate inference. I think the context is “for this use case”. Neither are saying never use Redux or useEffect, but are more about the common problem of people reaching for solutions that aren’t a good fit for their problem.
  • Gunax 4y ago
    I think I disagree, or at least we might disagree on what operations are common in React. When I have seen useEffect used, it's most often uneccesary. People are using it to create dependent state (ie. when x changes, then recalculate y) or to handle the result of an event. It's really only needed in components that handle fetch responses, which IME is much fewer than 99.9%.
• quickthrower2 4y ago
  There you go. I thought `key` was something you just needed when creating child elements, so react knows which ones are which. I didn't realize it could be used to create a new sandbox for state. But actually it makes sense! Because if you have a list of child items each with it's own state then React needs to manage that using the key. I never made this connection.
  • dgb23 4y ago
    It’s useful to think about key as the telling React of the identity of a component. Whenever you want a stateful component that can be identified by a unique name, you’ll likely want to tell that to React via key.
  • sickcodebruh 4y ago
    My concern with using `key` for this is that it’s somewhat of a booby trap for future consumers of the component. It requires some kind of documentation that you need to hope they’ll read. TypeScript won’t help you. It’s not common enough that they’ll think to go looking for it. It’ll break silently and they won’t know until there’s a problem. Is the best practice to wrap a keyed-to-reset-state component in an unkeyed component and then exporting that? Seems like an odd pattern.
    • aeroaero 4y ago
      Not necessarily, the component itself can work without a key. Adding a key is just one approach to resetting component state from a parent. If a component can’t work properly without a key it should be wrapped further to make it usable rather than documenting it for all consumers.
      • sickcodebruh 4y ago
        That last bit seems like a recommendation that should be in the docs. It’s sensible from a “don’t leave boobytraps” perspective but it won’t be intuitive to many people. It’s one more little rule to learn, another comment on a sizable chunk of PRs. While it may be idiomatic and sensible JSX, it seems like an outlier for React, and I wonder if there’s an opportunity to improve the developer experience of this very common use case.
• rawoke083600 4y ago
  I like these types of articles, I come here and do Ctrl+F "svelte" I'm looking to see who is brave enough :)
  • ihateolives 4y ago
    For my personal projects it's always Svelte now. Fits how my brain works. I used to love React, but I must be getting old now and wish to have as little complexity in my life as possible.
  • eckza 4y ago
    Sometimes I Cmd+F "elm", but only on days where I feel like picking a fight. ducks
    • giovannibonetti 4y ago
      Yeah, Elm solves all of those problems through its purity-enforcing compiler. It's a shame so few people know about it.
      • yakshaving_jgt 4y ago
        The surprising thing to me is how many JavaScript enthusiasts love to bang the FP drum but refuse to consider Elm. It makes no sense at all.
        • reducesuffering 4y ago
          Because Elm is functionally dead. Core libraries? Not updated for 2 years. Core compiler? Not updated for 7 months. It's only Evan, who is seemingly burnt out, and hasn't handed over progress to anyone else. A quick glance into the Elm community will surface this. Feel free to nerd out on an esoteric approach but all the other products coming out are generally shipping fast and bouncing approaches off each other using Next.
          • 4y ago
• yosito 4y ago
  Using a key to reset state when props change is a great tip. I was using an effect to do that.
• preommr 4y ago
  This is something that I really dislike about the react ecosystem. The devs and community leaders keep being impractically obtuse about how the framework should be used and is used. React isn't low level enough to be this unopinionated.
• nasir 4y ago
  A few months ago I need to build a small web app and decided to have a look at React. Pre Hooks, I had used React a lot so I thought it will be straightforward. Then I stumbled upon all these new paradigms wrapped in hooks to make an API call. Confused, I gave up and switched to classic Flask with template engines. Seeing this reminds of the time I was spending to understand these concept and use them. Quite funny that the whole React ecosystem is turning into a classic server rendered mechanism with core functionalities being deprecated. I'm glad I stayed away.
  • wetpaws 4y ago
    Just don't use hooks. Why people think they are obliged to do the switch eludes me, feels like some kind of cargo cult.
    • continuational 4y ago
      It's pretty clear that the class based API is a legacy thing in React by now. You can still use it, but the framework has moved on.
      • wetpaws 4y ago
        This is frankly framework's problem, not mine.
  • liendolucas 4y ago
    Same here. Flask with HTMX and bit of HyperScript (if you dare) has become very pleasant so far. I wished I had discovered it before. I do not know for sure if it can fulfill complex apps, but this also invites to rethink an app in terms of the original web instead, exchange HTML, not JSON + all the transformations that need to take place in the FE. I found the HTMX memes hilarious and very true actually: https://htmx.org/essays/ https://htmx.org/essays/ Maybe is time to rediscover simpler tools and frameworks.
• Gunax 4y ago
  This is a footgun I found at a few Amazon internal apps recently. I was able to clear away probably 3/4 uses of useEffect--some of which I was guilty of adding. Given how common this error is, there is definitely an unmet need. What people want is a listener, ie.: - recalculate a var whenever a prop changes (this is what useMemo is for) - trigger a function when a state changes (should be moved to the function that changed the state)
  • gardenhedge 4y ago
    That is not what useMemo is for. It's for caching a result and only recalculating it if the dependencies have changed. The aim is to optimize performance. It is not intended for listening to prop changes.
• liendolucas 4y ago
  For the less hyped and esoteric audience of the framework that does not want to go with hooks and remain with a simple dumb model I wish they don't deprecate the class based model but that seems to be already happening: https://react.dev/reference/react/legacy https://react.dev/reference/react/legacy. In few years in the future who knows with what new thing they will come up with. Meh.
  • TheCoelacanth 4y ago
    Every single one of these examples has a nearly identical anti-pattern using componentDidMount or componentDidUpdate. There's nothing here that's specific to hooks. It's just people misunderstanding the React lifecycle.
• batmansmk 4y ago
  I lead a 4 dev team working with a React codebase of 80k LoC for 2 years. Hooks' lack of orchestration mechanism, props drilling and its quirks, wrong dependency arrays, setTimeout not cleaned up, and other misuses of the framework were the cause of 7 of the 28 bugs we fixed in prod in March 2023 so far. Every other PR there is a debate around a hook lifecycle gotcha. Is it a lot? I think it is.
• rickstanley 4y ago
  // Good: This logic should run because the component was displayed useEffect(() => { post('/analytics/event', { eventName: 'visit_form' }); }, []); And then a wild 'exhaustive-deps'[0] appears! [0]: https://github.com/facebook/react/issues/14920 https://github.com/facebook/react/issues/14920
  • andrewingram 4y ago
    There aren't any function-scope variables used here, so an empty dependency array is correct.
• brap 4y ago
  I think we've reached the point where React is ready to be challenged by a new competitor. Unfortunately I haven't seen one yet.
  • wizofaus 4y ago
    LLMs may well obviate the need for further JS frameworks - at least ChatGPT seems to be just a capable of generating pure JS vs framework-based JS from what I've seen so far. At any rate the sorts of things it's good (and not good) at doing don't seem to vary with the choice of framework. Having said that, as long as there's an expectation the generated code still needs maintenance by human devs, there may be a reluctance to step back from frameworks.
  • Sammi 4y ago
    There are currently two new web frontend frameworks that are sharply on the rise: Svelte and Solid. Both do away with much of the complexity of React.
  • yakshaving_jgt 4y ago
    If you'd consider an old competitor, then Elm does everything better and is much easier to learn.
    • Sammi 4y ago
      Too closed off to the world. You can't win over the world if you are closed off to it. Elm has been going nowhere for ages now, and will continue to go nowhere, as long as they keep not listening and don't give people what people ask for.
      • yakshaving_jgt 4y ago
        As far as I can tell, people keep asking for runtime errors. That would defeat the purpose, and turn Elm into yet another JavaScript-like foot gun.
• sickcodebruh 4y ago
  My experience has taught me that when developers consistently use your tools “wrong”, it’s a sign that the tools themselves are the problem. The use cases described in this document outline common needs that shouldn’t be so easy to get wrong. It reads like a call to action for an expansion and rethinking React’s public interface via new hooks or utility functions. You can’t always document the pain away. I’m not a React maintainer so I don’t know how easy or possible this is, but considering all the fantastic things the team has done, there’s no way that this is their best. To paraphrase an old quote, “If you see bad code with your utility all day, perhaps your utility is the bad code.”
  • ep103 4y ago
    Joel on Software - The Pit of Success applies here, yet again
    • mcgwiz 4y ago
      <aside> Joel is a great but credit for this goes to Rico Mariani, originally quoted here https://web.archive.org/web/20100514093413/http://blogs.msdn.com/brada/archive/2003/10/02/50420.aspx https://web.archive.org/web/20100514093413/http://blogs.msdn... </aside>
  • gardenhedge 4y ago
    disagree completely. the problem is newbie devs are learning react without know javascript first
  • tadfisher 4y ago
    I submit that React would have appropriately zero users if it nailed down its API to only allow the "right" way of using it from day 1.
  • frodowtf 4y ago
    React would have needed its own domain-specific language to get around the implicit reference insanity and other quirks of JS.
• Capricorn2481 4y ago
  This is in line with how I was taught how to use React years ago. I'm surprised so many people are angry with these new docs. React has been such a productivity boon for us and every time I have to work in Angular, I'm reminded of how unnecessarily complicated it is for a frontend framework. Many useEffects can be replaced with event handlers and calculated constant variables
  • ep103 4y ago
    React is still easier to work with than angular, depending on your application, even with these issues. But these are still issues : )
    • Capricorn2481 4y ago
      What issues? This is an update to the docs to reinforce best practices that have been around for a while now. People are acting like there's been sudden breaking API changes. useEffect has always been a last resort technique, and even the old docs reinforced this. People saying things like "They recommended Next.js for starter projects, so they're giving up on SPAs?" both don't understand what Next.js is and, really, just want to be angry about something. The response to this has been absurd. Dan Abramov has been active in the community and transparent about the documentation, and he has gotten direct ad hominem attacks from the same community. It's just the same story: People that feel lost using React claiming the rest of tech world is fed up with it, and it will be dead next year. I question whether they even do frontend work that much, or are really backend devs forced to do it once in a blue moon. Meanwhile every other library/framework trying to "outdo" react just falls short in so many areas. I welcome the competition, but it's clear that these aren't the members of the community that should be tastemakers for frontend design.
    • willio58 4y ago
      A year ago I was applying for jobs (react jobs mostly) and got a take home project with angular. I shrugged and said why not? I stared at the angular docs for about 2 hours and emailed the recruiter saying “no thanks”. Angular is such a departure from anything I’ve used before. Meanwhile react is just simply component based and if you need things like global state you can add zustand and it all just makes sense. Angular felt like a ton of boilerplate (kinda like class-based react but so much more) and I just couldn’t imagine writing code in it daily. Later on I got a job in react with typescript and serverless functions and it’s a dream.
• satvikpendem 4y ago
  We need articles like these because people don't understand that React is fundamentally an idempotent framework. The function component or render method, well, renders every single time props or state change. Hooks are just a way to have some higher order state and if you think of React as UI = f(state), then the state variable also captures hook state as its input. It would be more clear to say UI = f(state, useState variable 1, useState variable 2, useEffect function 1, ...).
• whalesalad 4y ago
  Anyone here jump ship to Vue3 w/ it's composition API? I feel like Vue has the best of both worlds by offering a functional paradigm (composition api) while still supporting the classical object-based options API. I am slowly transitioning object/options components over to the composition approach in a continuous improvement approach. The ability to do that at my own leisure has been quite nice. I'm inclined to think Vue is the better framework, but React has a larger ecosystem. (Not intending to start a flame war here)
  • FallDownTS 4y ago
    The reactivity system in react is certainly "outdated" when compared to Vue, Svelte, Solid, or pretty much any newer framework. But it's just as you said, the larger ecosystem does have its benefits. There are a few libraries like Framer motion, that don't have equivalent support in other frameworks.
    • ojkelly 4y ago
      It’s all cyclical. Before React two-way-binding of data, known today as Signals, was the way we did things. Angular is probably the best example from the pre-react time of that. React came along with a philosophy of one-way-binding also known as unidirectional data flow. I’ve stuck with it because I think it enables much better local reasoning, and more predictable outcomes. Neither are outdated. I’d wager the most performance critical use cases would benefit from signals, things like tldraw. But unless you’re doing something which needs to paint every single frame (ignoring animation/transitions), the extra overhead and mental load required by Signals is excessive. It’s overly complex and harder to reason about. With no disrespect to Vue, Svelte, Solid, etc, they feel outdated in the way Angular does.
  • evnp 4y ago
    Yes, we're using Vue 3 and composition-style components over at https://radiopaper.com https://radiopaper.com. My only gripe is that Vue's standard templates can't be typed as thoroughly as JSX can (IME - after mixed experiences with Vetur/VTI[1]), but we've been gradually migrating everything to TSX via render functions[2] and finding it perfectly capable. Added bonus is an ease of composition of template code – small local-use components can easily be split out within the same file for readability, in contrast with Vue SFC's. Vue even has true "function components" now! [3] (nice to have in really minimal cases) [1] https://vuejs.github.io/vetur/guide/vti.html https://vuejs.github.io/vetur/guide/vti.html [2] https://vuejs.org/guide/extras/render-function.html https://vuejs.org/guide/extras/render-function.html [3] https://vuejs.org/guide/extras/render-function.html#functional-components https://vuejs.org/guide/extras/render-function.html#function...
• CSSer 4y ago
  I'm still confused. They present an example where they load data from local storage but do not make it clear how that data is passed out to the app. What if I'd like to always initialize my app's state with the data in local storage? Let's say I want to initialize from localStorage and pass this to context. Doing so triggers a hydration error in React v18 because the server-side value will never match the hydrated value once set. It seems like a job for useSyncExternalStore since that's what localStorage is (an external key-value store), but the ergonomics of the subscribe function seem odd to me.
• robopsychology 4y ago
  People talk about the benefits of a functional architecture with UIs and how I guess you can see it as a data stream where FP helps think about things, but surely Smalltalk-style OO with messages would be the best way to represent something that both requires a lot of back-and-forth but also widget state? Are there any OO-style web frameworks that are popular nowadays?
  • deleted 4y ago
    [deleted]
  • imbnwa 4y ago
    Does Apple's preference for the Delegate pattern touch on this?
• sroussey 4y ago
  It says not to use effects, but then suggests useMemo which is an effect!
  • jsmith45 4y ago
    I'm not sure that useMemo really is an effect in the sense that useEffect is. The useMemo callback is invoked synchronously during render, rather than getting pushed onto an effect queue like useEffect does. Even useLayoutEffect goes on an effect queue, and if it results in changes, will need to render a second time, while a changed memo calculation happens entirely during the single render pass.
• greenie_beans 4y ago
  this is great. i learned some instances where i've been improperly using effects. there are a ton of tutorials out there that teach new react devs the wrong patterns. really low bar of entry to put some article up on medium or dev.to about "useEffect tutorial". and then those devs go on to write their own tutorials that are misguided, etc
• tr0waway 4y ago
  You might not need react.
• gloryjulio 4y ago
  It's really tiring to keep seeing the bashing on the effect on hn. It's an advanced tool to replace hoc hell where you need reusable shared logic. In the doc it's even stated as such and also stated that it's for cross cutting logic. If you haven't seen hoc hell before when using classes, that only means your usecase was not complex enough for this kind of tools
• gardenhedge 4y ago
  awesome! I've always wondered why people relied on useEffect so much. I've been using it perfectly
• koromak 4y ago
  I despise the prevValues paradigm that crops up. Its even recommended in these docs, under "Adjusting some state when a prop changes" Having to keep a second variable around for every prop you need to compare is just miserable to work with. useEffect is less efficient, but so much more obvious in a situation like this. "I want to do something when this value changes, and ONLY when this value changes" seems like something React should be able to handle elegantly. It happens literally all the time.
• andrewstuart 4y ago
  React has jumped the server side shark.