I’m looking for a developer who can jump into an existing project for a very small, time-sensitive task:
Task: implement a masonry grid layout inside WeWeb
Why I need help: WeWeb doesn’t yet support masonry natively. I tried an NPM package, but ran into bugs and incomplete rendering. I’m not sure if the issues come from the package itself or WeWeb’s handling of it.
What I want: a quick, no-friction fix (custom CSS, a different package, or any other reliable approach)
Availability: ideally someone who can deliver the solution right away
The items displayed inside the grid would be dynamic (fetched from Supabase) and will have different height sizes, which is why I’m looking for a masonry (Pinterest-like) grid layout. I also plan on adding a filtering & sorting feature to the grid, so I need the solution to handle changes and resize automatically.
I can help with this and handle the grid setup so it works reliably within WeWeb.
Available to start right away and can deliver a quick, stable solution.
Let me know your timeline.
Happy to send over a flat rate once I have a bit more details.
Hey @jptrinh! Sorry for the late reply. I’ll try to give you as much details as possible, let me know if it’s missing any important details.
The solution works great with dynamic content, but it becomes a struggle when I start to apply changes to the collection in real-time.
The masonry layout listen to changes like resizing of the container, but it doesn’t listen by default to the number of items inside the list.
I believe that is fixable by calling their API with the “layout()” endpoint (see screenshot below), but since I’m not very technical, I simply added for now an action in every workflow that affects the collection in order to retrigger the masonry layout script.
I’m not sure in fact if that’s where my problem lies (you can probably tell me), because maybe the API relayout trigger will have a different way of animating changes to the grid (which is my problem).
With this workflow action, I managed to make real-time changes like filtering work, but the default animation makes it look buggy because it is applying to the grid because it’s moving some items elsewhere instead of simply stacking new ones at the bottom of each row.
As a workaround, I add a loading animation overlay on the whole grid to give time for the default animation to end.
However, that workaround isn’t ideal for the infinite load feature because it doesn’t really make sense to hide the already loaded items while the new ones get added.
If I don’t add any overlay, this is how the masonry layout animate when I retrigger the script to relayout all the new items, which isn’t really great UX:
Do you think the relayout API call would be the fix for this problem? Or should I just go with a custom coded solution?
