Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Custom RxDocument decorators #165

Closed
natew opened this issue May 12, 2017 · 5 comments
Closed

Feature request: Custom RxDocument decorators #165

natew opened this issue May 12, 2017 · 5 comments

Comments

@natew
Copy link
Contributor

natew commented May 12, 2017

Case

When you write a query and exec(), you get a list back of RxDocuments. Typically you can define methods() to add methods to them, but this isn't very flexible. This may be a more advanced use case, but for example I want to extend documents in a variety of ways. One would be adding observable values onto them. Another would be adding specific getters. Etc, etc.

Issue

Can't really hook into the internals to do this. Idea would be to be able to hook into preCreate for an RxDocument and decorate the instance or the class (or both).

@natew natew changed the title Feature request: Custom query decorators Feature request: Custom RxDocument decorators May 12, 2017
@natew
Copy link
Contributor Author

natew commented May 12, 2017

Actually, instead of having a methods object you give, would be nice to just give a class. This could then be extended by the RxDocument. This would also solve the getter issue we had before!

@pubkey
Copy link
Owner

pubkey commented May 12, 2017

I think adding a preCreate hook is an excellent idea. It would make everything more flexible.

@pubkey
Copy link
Owner

pubkey commented Jun 3, 2017

Done here
The hook is called postCreate because it runs after the RxDocument-instance is created.

@pubkey pubkey closed this as completed Jun 3, 2017
@natew
Copy link
Contributor Author

natew commented Jun 26, 2017

Just curious: postCreate was made non-async, was there a reason? I have a use case that would be nice to have async, but if its technically a lot harder it's not a problem.

@pubkey
Copy link
Owner

pubkey commented Jun 26, 2017

@natew postCreate was made non-async for implementation-reasons. If it could be async, next to every methode of rxdb would have been async.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants