Open braebo opened 3 months ago
doesn't addMany
just use bindMany
under the hood? If so could you do something like
function addMany(obj) {
const value = structuredClone(obj);
this.bindMany(value ....
}
then just return this value in the onChange?
because onChange
is a method on Folder
that is used lots of places by stuff other than addMany
, and addMany
could be called any number of times, and there's no way to link a specific onChange
event to a specific addMany
callsite
This is a follow up after talking through #29, which was motivated by the need to track changes when using
addMany
(notbindMany
) with an inline object.@ghostdevv The problem is encountered when doing this:
And you were asking for the value of
PAYLOAD
to be a reference to the object that was changed.This isn't a thing because there is no "object" internally anymore, just a tree of folders and inputs.
The
'change'
event is emitted by every folder, and it's used to react to any change in any input or subfolder input in the folder emitting the event. This is independent in many ways from the concept ofaddMany
.In order to access the values corresponding to the input object, you'd need to use the
allInputs
map of the folder being added to:I've yet to try that, as I'd normally be storing references as needed:
Nonetheless, this highlights one of the biggest unsolved annoyances I do have with the current API:
Getting the inputs back out of the gooey object kinda sucks thanks to the type-unsafe nature of a Map:
We could:
Option 2 seems better to me.
So. Currently, there are 3 ways to get a reference to an input:
addNumber
orbindNumber
for example.Folder.inputs.get()
- an internal map of all inputs by titleFolder.allInputs
- a getter than walks the tree and returns a newly constructed map of all inputs (don't love that)If
inputs
is converted to a typesafe POJO, it would feel even more grody constructing it every timeallInputs
is referenced. So I guess my question is:Whats the best way to construct and store this POJO map in a recursive tree structure like this one while maintaining the current API?
Off the dome, I suppose we could:
Folder.root
orGooey
instanceFolder._registerInput()
method (luckily all inputs go through it)allInputs
getter point to its position in the tree.I'm not sure if this is the best way to go about it, but it's the first thing that comes to mind. I'll try it out and see how it feels. If it works, it would solve both this and #29