UpdateWhere is a handy function

Post by adriaanmulder » Thu, Sep 14, 2023, 6:38 AM UTC

Thiez wrote: post #28

hnben wrote: post #15

Earlier quoted context omitted.

I don't like how it could result in surprises. e.g. you use it to update an array, but there are objects inside, which you accidentally modify. I think these surprises could be reduced if you turn them into explicit parameters in the signature, e.g. export const updateWhere = (whereFn, updatefn, thing, recurseArray=true , recurseObjects=true)

If `thing` contains any cycles then it will explode. E.g. const thing = {}; thing.self = thing; or const thing = []; thing.push(thing); If this sounds far-fetched to you just know that all DOM elements have these circular references through (for example) parent / child references. Also any non-enumerable properties that may have been defined on objects are lost. Basically the function is only suitable for recently pa…

That's a great point

Post by adriaanmulder » Thu, Sep 14, 2023, 6:43 AM UTC

binwiederhier wrote: post #23

Clever is bad, boring is good. As a senior engineer, you see things like this all the time from more junior engineers: way too generic code, done in an overly clever way, incompressible to most. I've spent countless hours telling junior engineers to "dumb it down" and "make it less generic". Not all features that exist must be used. And no, you don't have to combine them all either. That's why I dislike Scala, and li…

Is this really so hard to read?

  updateWhere(
    thing => thing?.guid === postId,
    post => ({...post, title: newTitle}),
    networkCache
  )

The alternatives as far as I can tell are:

- normalize network responses, so you can get the post directly by id. But this is notoriously painful to do well

- or the code that handles this name change needs to know every request that references the post with that id, and update those titles manually

Re: UpdateWhere is a handy function

Re: UpdateWhere is a handy function