refactor(frontend): drop watchjoin#2925
Conversation
| const v1node = v1nodes.value.find((n) => n.metadata.name === itemID) | ||
| const talosMember = talosMembers.value.find((m) => m.metadata.id === itemID) |
There was a problem hiding this comment.
The complexity of that function is rather big now as we call find twice here.
If we go this path I think we should build a map where n.metadata.name/m.metadata.id is the key and the value is the resource. Then look up the extra data in that map.
There was a problem hiding this comment.
It's absolutely worse, and a map is absolutely better, but will we be dealing with datasets large enough to care? If every list had 1k items it would probably take like 5-10ms to iterate this at the most.
If we are dealing with large data like that then sure, but if not probably not important. Mostly wondering cause it would be good for me to know to expect large datasets like that in places like this.
(Keeping in mind there is also pagination here, so at most, it is going to be 100 items -> 200 finds, if page is set to 100, which is pretty cheap)
There was a problem hiding this comment.
in any case, added now, easy change 🚀
| ...m, | ||
| spec: { | ||
| ...m.spec, | ||
| ...machineConfigGenOptions.value.find((c) => c.metadata.id === m.metadata.id)?.spec, |
There was a problem hiding this comment.
Same. Lets not use find there.
Maybe we can have a helper function computedMap(items, idFunc).
Then:
const machineConfigGenOptsMap = computedMap(machineConfigGenOpts, (c) => c.metadata.id)
...
...machineConfigGenOptsMap.value[m.metadata.id]?.spec,Drop WatchJoin and related code and replace with manual merging as needed. The complexity it brings is easily solved with array maps, and is rarely needed. Signed-off-by: Edward Sammut Alessi <edward.sammutalessi@siderolabs.com>
Type TList items using generics and a fake prop Signed-off-by: Edward Sammut Alessi <edward.sammutalessi@siderolabs.com>
|
/m |
3 participants
Drop
WatchJoinand related code and replace with manual merging as needed. The complexity it brings is easily solved with array maps, and is rarely needed. As a nice quick side benefit,TListitems is typeable now and use cases have been typed.Related #1471