christianalfoni / cerebral-react-baobab

A Cerebral package with React and Baobab
MIT License
13 stars 1 forks source link

Traverse tree then call method #7

Closed saulshanabrook closed 9 years ago

saulshanabrook commented 9 years ago

Is it possible to traverse the tree then call a method?

Like this action:

export default function setSynced (args, state) {
  state.synced.push('dfd')
  // or
  state.someMap.merge({hi: 'there'})
}
christianalfoni commented 9 years ago

Ah, no, to support different model layers it was chosen to use a generic signature. "state.mutation(path, value, value2, value3 etc.)". That is easily converted to anything :)

Even immutable-store which has that possibility you mention does not work that way with Cerebral, same state.mutation(path, value) siganture.

saulshanabrook commented 9 years ago

Do you think it would make sense to also support something like Baobab's select method? It seems like it could just be a wrapper around the existing syntax

saulshanabrook commented 9 years ago

I like to use it if I am referring to the same path a couple of times. That way I can select that subtree and operate on it, without having to keep referencing the absolute path

christianalfoni commented 9 years ago

Hm, yeah, though you could just:

var path = ['foo', 'bar', 'something'];
state.set(path, 'foo')
state.set(path, 'bar');

Do I understand you correctly? Do not see why you need to select a cursor, as a cursor is really just an array in the sense of doing mutations. Though you have to pass array on every mutation.

But yes, this is something still being explored. Now Cerebral has a hardcoded API to all model-layers. There has been questions about immutable-js too. So I am thinking about how to make the "state" object more dynamic, but yeah... hm hm, have to think about it more :-)

saulshanabrook commented 9 years ago

Yeah that totally makes sense, I am currently doing something similar to pass paths around. I can see the advantage of not adding much to the state, it forces you to do things in a simpler way and more uniform.

Before I was passing around just an ID to sub component, but then I would have to look for that element in the state whenever I wanted to update it. For example, to set the level of a certain item I would have to do something like this, if I knew its UUID:

  var systems = state.get(['synced', 'live', 'systems'])
  var index = systems.findIndex(s => s.uuid === uuid)
  state.set(['synced', 'live', 'systems', index, 'level'], level)

Instead in Baobab I would be able to just do:

tree.set((['synced', 'live', 'systems', {uuid: uuid}, 'level'], level)

However now instead of passing in the UUID to the action, I am just passing in the full path so it doesn't have to do this lookup, which is maybe the better solution in the long term anyway.

Did that make any sense? My point is basically, maybe it is good to not have as much flexibility in working with paths because it forces you to deal more explicitly with data paths, which is (maybe) more performant and maybe ends up being simpler.

christianalfoni commented 9 years ago

Hey @saulshanabrook ,

Ah yeah, jup, this makes sense. But you should actually be able to do this with the Baobab package, as the implementation just passes the array to the tree. Have you tried it?

saulshanabrook commented 9 years ago

Oh wow, no I haven't, that does make sense though, should have thought of that :)

christianalfoni commented 9 years ago

Let me know and we can document that on the package page :-)

christianalfoni commented 9 years ago

or this page I mean... hehe