Classes processing
ul opened this issue · 12 comments
Noticed two non-conveniences:
- {:class nil} produces class="null", but no classname is desired
- [:div.class1 {:class "class2"} produces class="class2", but merge is desired
- Looks like a bug that we should fix
- This is possible but would add some code complexity I'm not sure is necessary. Can you give some more use cases?
- is only point of shortcut, when some classes are fixed, but another is dynamic, like
[:div.win__content {:class (when mod? " win__content_mod")}— second class should be added only ifmod?is true, first one should always present. Handy to have this sugar, but not really necessary.
I can't check this and diff because develop branch renders only part of dom tree in my app without any errors shown. Investigating this right now. Also non-reactively is noop now? invalidate-rx is undefined and not used. How to wrap reactive element without registering it as dependency now?
I guess ivalidate-rx now is called register-dep? If yes then we need to update macros.
Specifically, in [:div [:div ...]] only outermost tag is rendered.
Excuse me for my short reports, I have no enough time to dive into subject these days and I don't tracked all changes which you made in code in develop branch, so I don't clearly understand how to debug it.
Oops! Well this was a pretty messy refactoring on my part - sorry. Hopefully in the latest commit I pushed on develop, this should be fixed. I'm hoping this will be the last major refactoring of the core API - I think this should make 3rd party integration much easier now though.
The result in my app is the same as before. Please see the code https://gist.github.com/ul/992bd5fcd1d27f06337f may be that will help.
in the latest development branch:
- bug still persist
- merge works fine
I just pushed a fix which sets .className to "" when :class is nil. Does that seem correct?
Works fine, thank you!