-
Notifications
You must be signed in to change notification settings - Fork 2
Description
(I apologise up-front for the bike-shedding which follows...)
This looks great! I have a Firebase-based prototype with 5 or 6 entities which I keep meaning to get back to which this will take a huge chunk of repetition out of, so can't wait to dig in.
How do you feel about an alternative syntax for building the schema which hides whatever implementation detail the child function is providing (or just does the child bit for you behind the scenes)?
e.g. the README example could probably be made to work something like:
var schema = FirebaseSchema.create(Firebase, HOST, {
'users': list({
':userId': hash({
'name': string,
'groups': index('../../groups', {
':groupId': boolean
})
})
}),
'groups': list({
':groupId': hash({
'name': string,
'members': index('../../users', {
':userId': boolean
})
})
}),
'messages/:groupId': list({
':messageId': hash({
'content': string,
'author': key('../../users/:userId')
})
}),
'messageFlags': list({
':flagId': hash({
'message': key('../../messages/:groupId/:messageId'),
'group': key('../../groups/:groupId'),
'count': number
})
})
});This also seems like it would lend itself better to modularising the entities (without needing a function wrapper) and even introspecting them later (my YAGNI alarm is beeping), or holding some additional meta info about them for generic use cases like auto-CRUD (my YAGNI alarm has melted).