fix-next(css): className to preserve root views classes - #7725
vchimev merged 7 commits into
Conversation
Sorry, something went wrong.
| const shouldAddModalRootViewCssClass = cssClasses.has(MODAL_ROOT_VIEW_CSS_CLASS); | ||
| const shouldAddRootViewCssClasses = cssClasses.has(ROOT_VIEW_CSS_CLASSES[0]); | ||
|
|
||
| cssClasses.clear(); |
There was a problem hiding this comment.
Why do we clear this at all? Maybe modifying the add method to not add a cssClass if it already exists would skip all of this adding and removing classes?
Also modifying cssClassses should update className.
Sorry, something went wrong.
There was a problem hiding this comment.
Actually just saw that cssClasses is a Set, so it should have only unique items, thus no need for even checking on add(). 🙂
Sorry, something went wrong.
There was a problem hiding this comment.
Yep, deleting all the new code and cssClasses.clear() works okay.
Sorry, something went wrong.
There was a problem hiding this comment.
Now we are left with only one problem - all the new root classes are not reflected in className, thus the user can't see them in the string or in DevTools.
Sorry, something went wrong.
There was a problem hiding this comment.
Okay, since cssClasses is not synced with className, it has to be cleared every time before adding classes, to remove any classes that are not in className...
Sorry, something went wrong.
| @@ -1036,11 +1038,23 @@ bindingContextProperty.register(ViewBase); | |||
| export const classNameProperty = new Property<ViewBase, string>({ | |||
| name: "className", | |||
There was a problem hiding this comment.
So as discussed offline with @vchimev and @bundyo currently there is a discrepancy between className and cssClasses -- if you try to get the className value it will not include any values that were added through cssClasses directly. One potential solution could be to update the className getter to return a concatenated string of cssClasses values.
Sorry, something went wrong.
There was a problem hiding this comment.
We will log a separate issue for this as apparently we will need to expose public API for customizing property getter/setter.
Sorry, something went wrong.
* feat(android): fix tab resource icon size based on spec (#7737) * feat(ios): add icon rendering mode for bottom navigation (#7738) * fix(ios-tabs): crash when add tabstrip in loaded event (#7743) * fix(css): parse css selectors with escape sequences (#7689) (#7732) * fix(ios-tabs): handle nesting proxy view container (#7755) * fix-next(css): className to preserve root views classes (#7725) * docs: cut the 6.1.0 release (#7773) * fix(android-list-picker): NoSuchFieldException on api29 (#7790) * chore: hardcode tslib version to 1.10.0 (#7776) * fix(css-calc): reduce_css_calc_1.default is not a function (#7787) (#7801)
PR Checklist
What is the current behavior?
When you set className to a (modal) root view, it overwrites view's default CSS classes.
What is the new behavior?
When you set className to a (modal) root view, it preserves view's default CSS classes.
Fixes #7709.