New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: replace Icon Picker #3814
base: neatbyte/icon-picker
Are you sure you want to change the base?
refactor: replace Icon Picker #3814
Conversation
@Pavel910, I have a question regarding the rendering of icons within page content. Previously, we utilized the Currently, icon rendering is handled by the Should I investigate this solution further, or do you have any other suggestions for how we might implement this? @adrians5j, maybe you can suggest smth about how to target this issue? |
After further investigation, I've realized that even if we manage to render the element correctly by type within Since I couldn't make We can consider using inline styles exclusively within our icon renderer plugins, but I'm uncertain if this is a suitable choice. @Pavel910, @adrians5j, maybe you have some ideas on how we can extract plain HTML for icons, and whether we should do this in the first place? |
@neatbyte-vnobis That's a very interesting problem. Looking at the code of our icon types, and how they use emotion, I think we can remove the use of emotion entirely. For regular icons, it will be SVG, just like it was in the original implementation. For emojis, it will be a div, and the styles for |
/cypress |
Cypress E2E tests have been initiated (for more information, click here). ✨ |
@Pavel910, when running Cypress tests, I encountered an issue with the
Alternatively, for an icon similar to the old
The object-based approach, particularly with the full SVG value, is not very readable. Maybe we can implement default value handling inside the |
@Pavel910 CC: @SvenAlHamad |
@neatbyte-vnobis Let's set the default value in form of an object. Readability doesn't bother me in this case, because icons are not frequently used via code. You can always extract the icon object into a separate file, to solve the readability issue. Mapping to a string.... I don't know, I'd rather keep the input and output value in the same shape. Let's keep it an object for now. |
/cypress |
Cypress E2E tests have been initiated (for more information, click here). ✨ |
Changes
size
prop toIconPicker
and styles for the smaller version (for PB sidebar).size
prop toIconRenderer
.removable
prop).align
prop toColorPicker
to correctly display it inside PB sidebarIconPicker
.IconPicker
andIconRenderer
with new ones.api-page-builder
andapi-headless-cms
changes (according to new icon value type).How Has This Been Tested?
Manual
Documentation
None