Skip to content

Conversation

@chpill
Copy link

@chpill chpill commented May 9, 2017

Implementation to illustrate my suggestion on #136

It works, using child-context-types and context-types to aggregate the different types correctly. But you have to be careful not to have a {:class-properties {:context-types ...}} in one of your mixins, as it will be applied last and override whatever you had in the top level :context-types (idem for :child-context-types)

Copy link
Contributor

@martinklepsch martinklepsch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's a worthy addition, context can be a useful tool but for that it needs to be composable.

Great to see you're using derivatives also 🙂

:childContextTypes
(when-not (empty? child-context-types)
(clj->js (apply merge child-context-types)))}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using a merge here that warns (or throws even) on conflicts would be good I think. This way using 3rd party mixins is "safe" and free from surprises.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you are right, it should probably throw in there. If the user really wants to override the context types put there by mixins, he can still do it with a {:class-properties {:contextTypes ... }} map that will override everything.

Also, thanks a lot for the derivatives library!

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants