Closed carloslancha closed 6 years ago
Hey @carloslancha, this is cool. But I have the impression that we have the same thing with its proposed approach to using content
, In soy some devs could also use this approach we are doing for our needs, as we do not want to use deltemplates
or data="all"
, perhaps the content approach would be more viable? Or do you find this approach a more elegant way to do it?
Yeah @matuzalemsteles it was a proof of concept. After talking with @jbalsas we're going with the $labelContent
approach.
Thx!
Why this?
As @jbalsas proposed in https://github.com/metal/metal-clay-components/issues/182#issuecomment-348138332 the best way to extend a component to fit our concrete needs is with deltemplates.
Why don't do it in this way?
This can be done by simply creating a deltemplate as an interface, with the params it's going to receive declared and then create variants in our modules, something like:
ClayCheckbox.soy
ClayCard.soy
But with this approach we are limited by the contract with the default implementation of the
ClayCheckbox.Label
, I mean, if we want to pass it a parametercoolParameter
we only can do it by adding it (obviously as optional) in the default implementation and all over the rest of implementations to comply the contract.Why to do it in this way?
So I prefer the following approach:
ClayCheckbox.soy
ClayCard.soy
As you can see here we do not have to define everywhere the
coolParameter
but where it's being used, in this case in the.cardLabel
template inside myClayCard
component, and we don't need to worry about the rest of extension that could exists.