preliminary support for bool: [needs help]
#347
Conversation
|
|
||
| if(!value) continue | ||
| prop = prop.slice(5); | ||
| result += `${escape(prop)}`; |
There was a problem hiding this comment.
does this need a space?
There was a problem hiding this comment.
@ryansolid this has been merged, pinging because Im not sure if you saw the question above, thanks
There was a problem hiding this comment.
Yeah it can but it depends which is why we have that logic after the condition. I'm going to slightly refactor to include it.
|
ok, I think this can be reviewed. The test I wrote works, there's still that failing auto-generated test that I don't know from where that's coming from. |
|
If you are curious why the tests fail its because we have some modes of universal rendering which are hybrid. Ie.. they combine both custom rendering and dom renderer. The problem was that your custom element |
|
Ah, I see, I will take a look at that if I run into this problem again, thank you! |
* preliminary support for ``bool:` * make code smaller * value of attribute should be empty when adding it to the dom * inline bool: attribute into the template when possible * fix prop name * undo space test
|
@titoBouzout one question I had on further review is why set the it as an attribute instead of a prop. I guess we don't know if all booleans are reflective which is fair. I suppose if it was sufficient people could have just used |
|
@ryansolid I think the main issue this solves is getting rid of the heuristic and being able to be explicit about the intention in a way that's simple and idiomatic to solid, complementary to Considerations... WC authors will do things in different ways, ones would expect a prop and others will expect an attribute. This could be relevant to the That being said, I am honestly still trying to figure out how all play together. I see a lot of benefices using WC and I'm trying to move to them, there are challenges. Joe expands on this feature in solidjs/solid#2158 and |
The idea of the
bool:namespace is to control if an attribute is present or not by evaluating its value to truthy/falsy. If it is truthy the attribute is added with an empty string as value, and if falsy the attribute is removed. It's similar toBooleanAttributesthat dom-expressions already considers but controllable by the user. This is specially relevant in the web components world where names are arbitrary and cannot be known beforehand.The namespace will make the intention clear and this cannot be done with dom-expressions
setAttribute.I am running into an issue trying to implement this feature and your help would be welcome
I have added 1 test for "custom elements"
babel-plugin-jsx-dom-expressions/test/__dom_fixtures__/customElements/code.jsWhen I run
npm run testit displays two failing tests:It looks like It's reusing the test I wrote in two different places and expecting for the same test two different outputs, I can't figure out what's going on with this test. Any ideas?