Closed nhunzaker closed 7 years ago
I don't immediately see the benefit of this. Just to have actions and domains live next to each other? "alias actions with string names"?
TLDR: I want to build up Microcosm's level of abstraction so that users can write even less boilerplate. To do that, it would be very helpful to know more about what they are trying to do.
But please read 😸
Longwinded response:
One benefit is that we could remove "tagging" magic (though we'd keep it for backwards compat, you could avoid it). The keys of the action
namespace on the domain could be used as the identifiers. I could see a domain like:
import uid from 'uid'
repo.addDomain('planets', {
initialState: [],
actions: {
addPlanet: name => { id: uid(), name }
},
register: {
addPlanet: (planets, record) => planets.concat(record)
}
})
If we provided more helpers out of the box, something I'd like to do, this could eventually be:
import { makeRecord, appendList } from 'microcosm'
repo.addDomain('planets', {
initialState: [],
actions: {
addPlanet: makeRecord
},
register: {
addPlanet: appendList
}
})
I also want to know all possible actions ahead of time. This is useful for tooling. We'd know ahead of time every single action and what domains registered to them.
This would be particularly useful for https://github.com/vigetlabs/draft-microcosm-graphql, so that I can build up a nice set of layers with escape hatches:
food for thought, typical disclaimer about how my ideas might be off base:
register
method?import { makeRecord, appendList } from 'microcosm'
repo.addDomain('planets', {
initialState: [],
actions: {
addPlanet: makeRecord
},
register: {
addPlanet: appendList
}
})
i feel like is the first step on the slippery slope leading towards you saying, "I want this to happen:"
repo.addDomain('planets', {
actions: [create, read, delete]
})
That last one may be a stretch of a comment, but I guess my general thinking is that while removing boilerplate is indeed useful, it also hides a layer of functionality, so we better make sure we're okay with hiding it.
is that not something we can do already with Domain's register method?
No, because I want the actual action function. A Domain's register method only has access to the action's unique identifier and the associated handler.
import { makeRecord, appendList } from 'microcosm'
That sure is neat looking, but does it overly assume that domains are typically used for managing very simple data structures?
It might be a bad idea. Almost all of the domains I have seen have handlers along the lines of:
null
I'd be fine holding off on that, or throwing away the idea entirely.
i feel like is the first step on the slippery slope leading towards you saying, "I want this to happen:"
repo.addDomain('planets', { actions: [create, read, delete] })
I agree that this is too far. However I think this is too much abstraction not because of premade functions for manipulating data, but because it obfuscates the integration points between actions and domain handlers. A user of Microcosm should not have difficulty controlling the flow of their program.
But still, appendList
instead of (list, item) => list.concat(item)
is hiding work for little benefit. I agree that we should only do this if it solves real problems and avoids pitfalls.
👍 seems like you have your head on straight about this. i will follow you into the dark!
Aww. I promise to bring flashlights and snacks.
I want a better way to alias actions with string names. This would be a breaking change because it would rework the way string actions are treated.
I would like to consider putting actions right next to domains. A domain module would contain both actions and handlers.
When a domain is added it will:
Things to figure out