fix: prevent sending updated props to plugin when props do not change [LIBS-514]

[tomzemp]

Implements LIBS-514

---

Key features

1. feature

Fixes app/plugin communication to pass props via post-robot only when the props provided to wrapper component have changed.

Description

Noted on ticket, but the intent of the wrappers was only to send a communication update when props passed to the component changed. However, when the parent with component updated, the plugins were deemed to have changed because of unstable object references (even when the passed props were themselves stable)

e.g. we had an app that passed stabled references to the whenever it rerendered:

const MyApp = () => {
const myFunction = useCallback(()=>{console.log("I would do something in the plugin"),[]}
const myString = "plugins are cool?"
return <Plugin myFunction={myFunction} myString={myString} />
}

however, when in the Plugin wrapper component...

const Plugin = (props) => {
  useEffect(()=>{
    // since the props updated, send them again
    post-robot_communication(props)
  },[props])
}

the overall props object was not itself a stable reference, hence while the individual values were not changing, the communication would reoccur.

---

Checklist

• Have written Documentation
  • This is a bug for a non-released feature, so no documentation updates needed at the moment
• Has tests coverage
  • tests will be written as part of general work to write tests for this service

[tomzemp]

this is the fix. I'm not sure I like this solution but since it's unknown what props are actually going to be passed, this was the best way I could come up with handling the dependency array.

[kabaros]

shouldn't the memoized value change if the values of the propsToPass change, not just the keys? will that be the case now?

[tomzemp]

🤦‍♂️ thanks @kabaros. Yes; this should have been [...Object.values(propsToPass)]...but now I think I remember that I did that originally, but then thought that the order of the props wouldn't theoretically guaranteed to be in the same order on the object, hence it might be better to do something like [...Object.keys(propsToPass).sort().map(k=>propsToPass[k])], but then I get a type error:

  No index signature with a parameter of type 'string' was found on type '{ propsToPass: PropsObject; }'.

And then I tried to explicitly declare propsToPass as an object with string keys (I made an interface of

interface PropsObject {
  [propName: string]: any;
}

but that did not resolve the type issues 🫤

I've pushed a change to [...Object.keys(propsToPass).sort().map(k=>propsToPass[k])], but let me know if you have tips about what I could to fix the type warnings 🙏

[dhis2-bot]

🎉 This PR is included in version 3.10.0-alpha.7 🎉

The release is available on:

• npm package (@alpha dist-tag)
• npm package (@alpha dist-tag)
• npm package (@alpha dist-tag)
• npm package (@alpha dist-tag)
• npm package (@alpha dist-tag)
• npm package (@alpha dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[dhis2-bot]

🎉 This PR is included in version 3.11.0-alpha.1 🎉

The release is available on:

• npm package (@alpha dist-tag)
• npm package (@alpha dist-tag)
• npm package (@alpha dist-tag)
• npm package (@alpha dist-tag)
• npm package (@alpha dist-tag)
• npm package (@alpha dist-tag)
• GitHub release

Your semantic-release bot 📦🚀