You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
dbauszus-glx opened this issue
Oct 18, 2023
· 2 comments
· Fixed by #1132
Assignees
Labels
BugA genuine bug. There must be some form of error exception to work with.CodeIssues related to the code structure and performance.FeatureNew feature requests or changes to the behaviour or look of existing application features.RFCRequest for Comment or Change.
The style objects (eg. default, highlight, selected, cluster) are always assumed to be style objects. A style configuration within a style object would create a valid style which is wrong.
There must be checks on the style input. The style should be sanitised with warnings.
strokeColor, fillColor were introduced only for the Object.assignment/spread to work. This is legacy code from a time when there was no merge method, no icon nesting, etc.
It has to be decided how arrays (eg. icon:[]) should be handled. At current arrays will overwrite the existing icon[array]. The style itself may also be an array.
The text was updated successfully, but these errors were encountered:
dbauszus-glx
added
Bug
A genuine bug. There must be some form of error exception to work with.
Feature
New feature requests or changes to the behaviour or look of existing application features.
Code
Issues related to the code structure and performance.
RFC
Request for Comment or Change.
labels
Oct 18, 2023
A style configuration as shown below will throw thousands of console warnings from the merge.mjs module. This was resolved by wrapping each object in the cat in style, but this should be done in the framework.
Interesting issue. The merge util probably shouldn't warn if there if an item checked to be an object is an instanceof HTMLElement. The warning doesn't really add anything.
The huge amount of warnings makes me think whether the style should be merged for each feature on each render.
Which in turn validates the warning since we would not have thought about this unnecessary processing step before.
BugA genuine bug. There must be some form of error exception to work with.CodeIssues related to the code structure and performance.FeatureNew feature requests or changes to the behaviour or look of existing application features.RFCRequest for Comment or Change.
Style objects (eg.
style.default{}
) are assumed to be a base style which can be modified by assignment.Style assignment checks whether the object has a style component. Otherwise the whole object is assumed to be the style.
The example below will alter the default style fillColor and adds fillOpacity to the style block.
The output will be:
The style objects (eg. default, highlight, selected, cluster) are always assumed to be style objects. A style configuration within a style object would create a valid style which is wrong.
This will create:
There must be checks on the style input. The style should be sanitised with warnings.
strokeColor, fillColor were introduced only for the Object.assignment/spread to work. This is legacy code from a time when there was no merge method, no icon nesting, etc.
Styles should be proper objects using merge.
It has to be decided how arrays (eg.
icon:[]
) should be handled. At current arrays will overwrite the existing icon[array]. The style itself may also be an array.The text was updated successfully, but these errors were encountered: