It’s been almost three full months since I became a professional developer, and in that time my team and I launched the new Torque website. This was the team’s first foray into Gutenberg and React, and my first real foray into it. I’d explored a few things and knew some concepts, but still struggled in some areas. The blocks we ended up creating work, however there’s room for improvement.
We created two separate blocks that needed shared functionality. After trying to fix the bugs in those blocks we came to the conclusion that we should just have one block that could cover all of the use cases of the two blocks. This may sound complex, and it is. It’s a block that’s meant to be used in place of two different blocks with those blocks and displays having different markup on the frontend.
One of the main challenges with this Post block is I need to be able to show either the latest posts, or show specifically picked posts. This means I need attributes that correspond to values in a WP_Query or REST API call, and that these values should be saved in the block so that the frontend is able to process them.
So I setup attributes for order, orderBy, categories, per_page, etc. I used a QueryControls component to set the attributes in the sidebar, but I need the same QueryControls component in the PostPicker component that I created. This component is a Modal window that pops open that has query controls, and displays a list of posts next to a checkbox. When you check the box, the post ID is added to an array that is also an attribute.
The main challenge I ran into is that when I was using the QueryControls in the PostPicker component the query would update behind the modal too and result in multiple components re-rendering but that’s not what I wanted.
How should I approach this?
I was reading a lot of the React documentation yesterday, especially around Functional Components vs Class Components, as well as State management. My thinking now, instead of having each QueryControl component control attributes, what if we use React’s State Management hooks to manage the QueryControls for the PostPicker, while the attributes stay attached to the main QueryControls component.
There’s a lot of work to be done still with the new editor, and there’s a lot to learn about the inner workings. We already see a large number of Block Suite plugins, but I feel like not many of them are pushing the limits yet, mostly due to the lack of documentation about what the limits are. I get my blocks into really weird states but I think this exercise of creating this Super Post Block proof of concept, to bring back to my team is definitely going to open up an avenue for me to get back into technical writing to contribute back to the WordPress community so that others don’t struggle as much with the same issues I’ve ran into.