The current Nav-Block presets don’t work, have styling issues and it’s impossible to add TW classes to it.
Styling Issues
Open the Post Editor/Site Editor
Make sure to reset to Tailwind mobile first breakpoints
Add a vanilla Nav-Block, select with preset
SM breakpoint has no styling, because it’s starting at 768px
Style selection breaks
1.Select Primary → Styles → Preset (Esprit i.e.)
2. Nothing happens, due to JS error:
react-dom.min.js?ver=18.2.0:10 Uncaught ReferenceError: newkey is not defined
at index.js?ver=1.4.0.1:3:2044137
at Array.forEach (<anonymous>)
at Pe (index.js?ver=1.4.0.1:3:2043865)
at index.js?ver=1.4.0.1:3:2043052
at Array.forEach (<anonymous>)
at _e (index.js?ver=1.4.0.1:3:2043039)
at Object.onChange (index.js?ver=1.4.0.1:3:2077701)
at onChange (index.js?ver=1.4.0.1:3:1497002)
at index.js?ver=1.4.0.1:3:5369756
at t.onChange (index.js?ver=1.4.0.1:3:5327172)
(anonymous) @ index.js?ver=1.4.0.1:3
Pe @ index.js?ver=1.4.0.1:3
(anonymous) @ index.js?ver=1.4.0.1:3
_e @ index.js?ver=1.4.0.1:3
onChange @ index.js?ver=1.4.0.1:3
onChange @ index.js?ver=1.4.0.1:3
(anonymous) @ index.js?ver=1.4.0.1:3
t.onChange @ index.js?ver=1.4.0.1:3
t.setValue @ index.js?ver=1.4.0.1:3
t.selectOption @ index.js?ver=1.4.0.1:3
I.f @ index.js?ver=1.4.0.1:3
Xa @ react-dom.min.js?ver=18.2.0:10
B @ react-dom.min.js?ver=18.2.0:10
W @ react-dom.min.js?ver=18.2.0:10
qe @ react-dom.min.js?ver=18.2.0:10
Ke @ react-dom.min.js?ver=18.2.0:10
(anonymous) @ react-dom.min.js?ver=18.2.0:10
dl @ react-dom.min.js?ver=18.2.0:10
V @ react-dom.min.js?ver=18.2.0:10
Je @ react-dom.min.js?ver=18.2.0:10
pe @ react-dom.min.js?ver=18.2.0:10
fe @ react-dom.min.js?ver=18.2.0:10
Setting Classes Impossible
It’s not possible to set classes on child elements in the navigation builder. This way it’s impossible to use Tailwind on it.
Saw you changed some parts of the Nav block in the last update.
Please have a look on the preset styles not working. This is a real show stopper for me.
This is on my to-do list but requires quite some thought on our end before we put this into practice. Why?
Simply because all users don’t set their base breakpoint on the lowest or highest media entry, which means that we would have the same type of bug report if we didn’t account for every possibility out there. Also, this means that we can’t predict what the breakpoint values for lg, mg, sm or the multitude of user created ones will be… Lots to plan for.
I was considering bringing the breakpoint transfer logic we have into the Nav block more specifically so that the user can interchange preset styles breakpoints without affecting other blocks (this would also solve the issue of requiring us to have multiple presets that might not apply in specific circumstances).
While I appreciate this can somewhat slow down getting a Nav block set up when designing in mobile-first, it’s important to note that you can start with a blank slate, and that the Nav block does work on desktop-first or mobile-first setups.
I know that navigations are the toughest parts in frontend development and a supreme discipline. In this case, I believe a working, yet basic, Navigation block could be achieved way easier and quicker.
We are dealing with just one crucial user setting. That’s the decision where the modal is visible. You could add a switch for “from/below” to cater for flexibility.
Example UI Design
My guess is that the style presets in their current form are hard coded and the culprit to this matter, right?
So it might be possible with this MVP:
The actual breakpoint numbers are known to Cwicly and generating the CSS based on the presets could depend on that single value the user chose earlier.
So we practically just have one decision and two ranges where to apply styling.
But I may be wrong about that, because I don’t know the inner workings as they are now. Maybe you could shed some more light on this in that case. I’d love to see this working again and possibly help out one way or another.
I’m quite aware that the base functionality is there. But to be honest, this particular block was one of the big selling points for me that actually made me buy a Cwicly license! You put so much effort in this like no other page builder / framework before and I deeply appreciate that. And the time it worked, the marketing was right: Get up and running in no time… literally “Cwicly”.
I’d like to get taken back to that promise. You get the point.
I appreciate you putting this down, and as I have said, we have to make sure that the process for presets applies correctly for every circumstance.
The setting you propose is too general, and doesn’t take into account the possible changes a user might have made to the Nav block that he doesn’t want to see applied to a different breakpoint, what defines a preset, should preset styles be locked in… I can go on and on with many conditions that aren’t met with your proposal as it is simply too rigid and unrealistic.
Just to make things clear, as your messages do instill some doubt: the Nav block is completely functional and usable whatever your breakpoint setup looks like.
This is not base functionality, but full functionality.
The presets are cosmetic and don’t affect functionality.
While I truly understand that the functionality is undoubtedly existent from a developers point of view, please understand that for me as a customer it is not full functionality if I can’t pick presets like it was possible a few release ago.
And again, yes, as frontend dev myself I could build everything by hand. But this is something I like to avoid. This is why I opted for a solution like Cwicly.
But before we get into some meta discussion here, I’d like you to ask if it makes sense to just close this Bug and re-open the specific sub topics of the matter, because there seem to be some underlying JS errors as well?
