Animation Controls, Form Submissions, Bricks Slider Events and much more! - Bricksforge 0.9.7

[@interculturalcommunication3889]

Jeeze man, what do you have planned for version 1.0? At this point I'm expecting Bricksforge 1.0 will just build the whole site for me and serve me truffle foie gras while I wait for it to finish. Spectacular additions Daniele! Thank you!

[@scarlydesigns]

I have never been so in love with a plugin before 😍. Thank you Daniele!

[@DanielRaghu]

Can't imagine building in Bricks without Bricksforge these days. A must have!

[@himanshuagarwal1068]

Why? Sorry, I build in bricks myself and am curious as to what uses of bricksforge make it such a must-have.

[@DanielRaghu]

@@himanshuagarwal1068 it's more for our use case - animations (especially with the new slider events), advanced forms (multi step, database submissions), control over elements, and a few more but primarily the first two. You can use other plugins for those but with Bricksforge making advancements (it's not even a 1.0 product yet), it's a no-brainer at times. Of course, that depends on each use case. Edited to add that the mega menu function is also great.

[@Buttholio]

"Done.... There is nothing more to say" 😎 It's getting embarrassing how often I have to say "best Bricksforge release evarrr" but here we are again :) epic release

[@maxziebell4013]

I freaking love the new UI… Mic Drop! 🎤🤓

[@pepitogrande]

Wow, another great update. Thank you, Daniele :)

[@56k-web]

This is huge! Love the Pro Form!

[@theskatingchoreographer]

This is so SICK! I LOVE it! More and more impressive every time there is a new update Daniele! Thank you SO much for all your efforts!

[@daveden2]

Impressive!!! You're constantly making our lives easier.

[@rebelinc]

impressive work, welldone

[@dahunsi]

Great update.

[@Skratchable]

great work, as always!

[@nikoweb]

Awesome!

[@dynamic-homepages]

really awesome =)

[@Buttholio]

Woot woot!

[@buntuscainte4987]

excellent

[@Pxwahid]

Nice. Would be nicer if we could make the calculations even simpler, just like you made the animation simpler. Keep on the good work.

[@maxziebell4013]

What was the reasoning to do calculation in the {} instead of evaluating as JS with an execution context (JS proxy approach)?

[@bricksforge]

Hi Max! 🙋🏻‍♂ Great question! :) The wrapping {} are used only for the form field IDs to clearly separate them from the static data input. This is the first reason for this design choice. Also, the following thoughts were crucial: 1 I think It's safer since you're not directly evaluating JavaScript code, which can introduce security risks. 2 We have more control over the allowed operations and syntax. Of course, there are always advantages and disadvantages. I thought this approach was subjectively the most suitable way :)

[@vigilantezack]

When I create an event using the slide events, it asks for the Bricks ID of the slider. Because it can only use a unique ID, if I have other pages that use the same slide with same animations, I have to copy the custom event so I can put in the different ID. Can the selector just be a normal class selector like regular timelines use? Why force me to use an ID, which makes it impossible to have global or re-usable sliders? And I already tried setting a custom ID in the Bricks CSS panel to match with my other slides, but Forge won't recognize when I use a custom ID and says no slide is found with that ID. This makes it really hard to simply clone a page and have the same slider on it, because all the animations break due to the selector of ID only.

[@bricksforge]

@@vigilantezack The slider ID has nothing to do with selectors. It’s the ID of the splide instance. Once created, it will always be statically saved in the bricksData object. A class or a dom node would make no sense here, as they are not holding the id of the instance.

[@vigilantezack]

@@bricksforge Thanks. This isn't the way Forge presents the field, it does say "Slider ID", not "Splide ID". And the little info bubble says "Slider ID without prefixes". Again, not "Splide ID", but "Slider ID", and why say "without prefixes"? Do Splide IDs have prefixes? It obviously sounds like it's asking for the normal DOM ID of the Slider element. Maybe this could be worded better? But that leaves the same issue. If I have a hero slider on a lot of pages, I can't clone pages or copy the slider because I have to copy and set a new ID on every single instance. I know there could be potential bugs using the same ID on a slider across multiple pages, but it seems like something that makes sense. I want to be able to just copy a slider or copy a page and have that slider work right away without having to fudge around with animations again because they break every time it's copied. That makes it especially hard for end users who want to clone pages and update them. Why can't we set a custom ID and have the bricksData object reset? If that's not possible, then Forge needs a way to link the Splide ID back to the actual Slider element we're using so that it can be copied. If not that, then perhaps allow us to create customized Splide and DOM IDs that are static and belong to that slider no matter where we copy it. Or maybe there is some other way to solve this?

[@bricksforge]

@@vigilantezack We have tried to make this easier to understand for beginners. Bricks always creates the splide ID based on the element ID. If the element is #brxe-1234, Bricks creates a splide instance 1234. However, if the ID is changed, Bricks does not change the ID of the splide instance. This is not usually necessary. We also don't want to interfere with the Bricks Logic, as this can have negative side effects. Bricksforge does everything it is supposed to do here. It expects a splide ID to know on which slider instance the action should be executed. How to minimize the effort when migrating pages is outside the Bricksforge scope. CSS classes do not help here.