I think "Keep tag options primitive" could be more helpful

[gregorypratt]

Thanks for this best practices, its really good!

This is my personal opinion of course but keeping tag options primitive is a bit of a misnomer.

It depends on the problem you're trying to solve. Objects get passed byref which is nice when you want your tag to change the values of the options passed in. E.g.

http://plnkr.co/edit/MBsDinTB4HfKA7laUUk5?p=preview

Another point is the beauty of object oriented programming where you can change how the data passed into a function is used without interfering with the interface. For example:

<my-cal num1="" num2="" num3=""></my-cal>

is better as

<my-cal nums=""></my-cal>

so when you want to add more than 3 items, you can. It's a simple example, but its the principal I'm talking about!

[jbmoelker]

@gregorypratt thanks for the feedback!

I do agree it's not always possible to stick to primitives only. It's meant as a rule to make your tags expressive and easy to understand by other developers. But some data structures don't fit well with that concept. That's why we also added "collections and well-known objects" may be exceptions. In your example I agree that a collection of numbers makes much more sense than individual attributes for each number. That would make the tag's API needlessly inflexible. I imagine we'd do something like this http://plnkr.co/edit/RvPuBP?p=preview

This rule is also hard to combine with state control via Flux or Redux as that would mean you typically pass large objects down the application. I imagine we could add a rule about smart vs dumb tags when using such a setup.

Suggestions on how to rephrase this rule are more than welcome.

[jbmoelker]

Since I don't think we're coming to a conclusion on how to update the guide based on this thread, and there has not been any recent activity, I'm closing this issue.