These params can't be found in STATE or your Class:

[robframpton]

If I have class A, that extends class B, and the soy template for A implements STATE params from B it will show the following error.

These params can't be found in STATE or your Class:

The parent class needs to be resolved and parsed as well. Obviously that makes things a lot more complicated :)

[mthadley]

My immediate thought is that we could just skip validation for classes that do not extend directly from Component, since we can't be sure what the developer is doing. In the future, it would be nice if we could do all those things you mentioned, though.

[mthadley]

So with c362df8, we will just skip those files for now until we can find a better solution.

[jbalsas]

After #9, I also got hit by this now...

File - packages/clay-link/src/ClayLink.soy

     These params can't be found in STATE or your Class:
     
     elementClasses

Also, is there a typo in the message, where it should say STATE of your Class?

We can't ignore all the files, though 😂

Now that we have .soycriticrc, maybe we could have something like this?

{
    // Been toying with other names such as `classTemplateParams`, `classState`... 
    // Not sure what would be a good name for this
    "renderState": {
        "Component": ["elementClasses", "visible"]
    }
}

[mthadley]

It's actually just a bad message on my part. I'm trying to say it can't be found in STATE or as a method of your class. I need a wordsmith here, quick! 😄

Yea, I'm open to something like that. A default set of STATE attributes.

[jbalsas]

My first instinct was to go with some globals à la eslint

{
    "globalParams": ["elementClasses", "visible"]
}

That would of course be easier to implement but also more prone to error since it disregards the inheritance chain completely. Maybe something like:

{
    "implicitParams": {
        "Clay*": ["elementClasses", "visible"],
        "OtherTemplate": ["foo", "bar"]
    }
}

What do you think?

[mthadley]

@jbalsas I really like this idea. Let's go with it.

[mthadley]

@jbalsas @Robert-Frampton Are there any use cases not covered by the new implicitParams configuration? Can this be closed now?

[jbalsas]

Based on deprecate/metal-clay-components#65 it looks like we can... ☺️