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

  • (nodebb) in reply to Steve_The_Cynic

    Ah indeed the metaphorical French flamethrower approach to code refactoring would apply nicely here.

    As the mere mention of flamethrowers does seem to offend people who can't understand deadpan sarcasm, in a startup during the dot-com era we used to call that the "select all, delete recode" method. It's less poetic yet worked better for our Americans fellow coworkers.

    Addendum 2026-03-12 12:38: In a C++ codebase, the method was best used at the file/class level: open file, select all, delete, recode the entire implementation without touching the header. It had it's obvious pros and cons.

  • (nodebb) in reply to Ralf

    In a C++ codebase, the method was best used at the file/class level: open file, select all, delete, recode the entire implementation without touching the header. It had it's obvious pros and cons.

    The most obvious drawback is that it's quite possible that this will not, in fact, delete the entire implementation, seeing as how you can, among other things, define (write the contents of) member functions directly in the class definition in the header. (Ref: inline functions, template member functions, template inner classes, template outer classes, etc.)

  • Angela (unregistered) in reply to Ralf

    I live in Maryland, the one state in the US where flamethrowers are illegal. So, sadly not a solution to any of my refactoring woes.

  • Robin (unregistered)

    Aside from all the problems with this in React code, the most obvious WTF is awaiting things that are not asynchronous. Not that it will often break code, but it's definitely a sign of a developer that doesn't know what they are doing.

    Mind you, I'm assuming here that RowValue and friends are normal arrays. But I guess we don't know for sure that they're not instances of some custom class which has asynchronous methods called push etc...

  • AzureDiamond (unregistered) in reply to Maia-Everett

    for the second question, you need to do something like setArr(arr.toSpliced(idx, 1)) to remove a element. you can also use mutating splice but its not really good style. for more complicated changes the standard is the immer library where you get a "fake mutable" copy of the value. that looks something like setArr(produce(draft => { draft[idx] = draft[0]; }))

  • (nodebb) in reply to Angela

    not a legal solution to any of my refactoring woes

    FTFY.

Leave a comment on “Awaiting A Reaction”

Log In or post as a guest

Replying to comment #693075:

Log Out

« Return to Article