You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There may be some cases (rare) that you would need two different shims (or more). The problem right now is that the last registered shim wins. Since can is global and can-validate attaches to can.validate, anything done to can.validate is carried over to all instances where can-validate is used.
If can-validate instead used a factory pattern, we could pass whatever shim we wanted for that given instance.
Not sure if this is a good idea or a bad idea. It might not even be that big of a deal. Either way, I'd like to come up with a decision for this because it really defines how can-validate should be used.
The text was updated successfully, but these errors were encountered:
@Macrofig I agree with this thought. Consider modular, open-sourced Maps that have their own validation built in. Community users could simply find the Map/Model they need and pull it in without worrying about having to refactor the validations.
How to implement, on the other hand, is not as clear to me at this time... :P
There may be some cases (rare) that you would need two different shims (or more). The problem right now is that the last registered shim wins. Since
can
is global and can-validate attaches tocan.validate
, anything done to can.validate is carried over to all instances where can-validate is used.If can-validate instead used a factory pattern, we could pass whatever shim we wanted for that given instance.
Not sure if this is a good idea or a bad idea. It might not even be that big of a deal. Either way, I'd like to come up with a decision for this because it really defines how can-validate should be used.
The text was updated successfully, but these errors were encountered: