• (nodebb)

    Code that you have to carefully, slowly, pick through and gently refactor

    More precisely, code that you have to refactor using a possibly-metaphoric flamethrower.

    Or a real one, take your pick.

  • 516052 (unregistered)

    Flamethrowers represent a workplace hazard and using them to enforce code quality through corporal punishment can lead to regulator complaints about workplace safety. Especially if you are operating within a shared office space. Please stick to the approved method of force feeding them milk and honey and tying them up next to an anthill to rethink their choices.

  • Hanzito (unregistered)

    I don't think there is a truly reactive JS framework. They're all shoddy, relying on asynchronous signals and global sychronization moments, while maintaining multiple states, and trying to avoid update cascades. I think this WTF is caused by two programmers who don't understand React in all its gory details. Not that I blame them for that!

  • (nodebb)

    Ah, the good old days of discussing the pros and cons of various LARTs.

  • (nodebb) in reply to 516052

    Ah, but I wasn't suggesting that the flamethrower should be used for ... chastising ... the offending programmer(s), nor for menacing them.

    No, the idea was to apply it to the code...

  • (nodebb) in reply to Steve_The_Cynic

    As a monk in good standing, I applaud your attitude. As an observer of both private and government workplaces, I feel obliged to ask why you would trust having such a devastating physical weapon around your cow-orkers when they've proven they can't even handle code.

  • (nodebb)

    I'm not that familiar with React, can someone explain what's wrong with this code? Does React not allow changing a useState object and then calling the setter to notify React that it was changed? And I'm confused that calls to splice and push are awaited, does this even do anything?

    What's the idiomatic "React way" of changing a reactive array?

  • Tim (unregistered) in reply to Maia-Everett

    it's not that easy to explain if you don't already understand React, but basically your code has a "render" phase which generates the UI from the current state. If some event happens that causes the state to change you can't just update state variables directly; you have to call "setState" methods which will then make react run the render phase with the new state.

    However after calling setState, the previous state is still in effect until the next render happens. The idea behind this is to make it easier to reason about the code because you know the state is constant while you are processing any events or while you're rendering. Unfortunately it's not always straightforward in the real world to figure out what's going on.

  • (nodebb) in reply to Tim

    The idea behind this is ... the state is constant ...

    The state can never be considered "constant" when there are end users and clickydoos.

  • (nodebb)

    "Please stick to the approved method of force feeding them milk and honey and tying them up next to an anthill to rethink their choices." Or as one instructor suggested, put them on an isolated network and have them do software testing.

Leave a comment on “Awaiting A Reaction”

Log In or post as a guest

Replying to comment #693050:

Log Out

« Return to Article