Closed slampenny closed 7 years ago
Hm, I don't disagree.
It might be similar to this:
// Clients can't interact with the `params` object, so the seeder could just stick `{seeder: true}` in there.
//
// The hook can then just delete `params.provider`, and bypass the auth filter.
function seedHook(hook) {
if (hook.params.seeder === true)
delete hook.params.provider;
return hook;
}
// Kinda tedious to this, but here's the nested service...
app.use('/users/:id/clients', (req, res, next) => {
req.feathers.id = req.params.id;
return next();
}, {
get(id, params) {
return new Promise((resolve, reject) => {
db.collection('clients')
.find({userId: new ObjectId(params.id)})
.then((err, data) => {
return err ? reject(err) : resolve({data});
});
});
}
});
// Your seeder config needs to pass the user id to the client seeder, or else you can't seed...
// Which brings me to this idea:
const seederConfig = {
path: 'users',
// ...
// If we pass the created context, along with the 'seed' function to a callback, then we can seed clients?
callback(user, seed) {
// Return Promise or synchronous computation, doesn't matter
return seed({
path: 'users/:id/clients',
params: {id: user._id},
template: {foo: 'bar'}
});
}
};
I need to add more tests to this library, regardless, so I'll make sure to add provisions for this. As it is, I haven't touched this codebase in months, because I was under the impression that nobody was using it.
Open for suggestions
Seeders should work on models for a variety of reasons.