I’m experimenting with creating a timeline in WeWeb.
It actually works, but I’m worried about performance and it feels slow. Tested with 30 days and 4 “entries”. It is understandable as I’m loading 1 div for each day between two (dynamic) dates, with components and div inside. Which results in a bunch of elements.
I know the editor is slower than the build, but I still think this may be a a bad solution. If i’m wrong then great.
This has been one of my most challenging problems going from traditional backend developement, to frontend developement, learning how the drawing of the elements affect performance. I still don’t feel I master it completely in weweb, and there are probably others that can offer more knowledge, but I have some pointers that I feel help me.
Use set widths and heights, makes it easier and faster for the browser to draw. Hundreds or thousand of divs that resize based on dynamic content is not fun for the browser.
Use as simple structure as possible, also inside each of your components.
Learn about infitine loading strategies.
The last one is by far the one strategy that gives the most back in performance, and you can use a combination of strategies to achieve a near instant loading page with thousands of entries. I have created a search results table with over 10.000 rows loading in under a second, in weweb with the following strategies:
On first load, detect viewport size. Using height/width of viewport element. Load just enough elements to fill the viewport. Set height of your scrollable element to the total know height by calculating the number of elements.
When user scrolls, calculate the placement of the viewport, and move the divs using transform. That means, we just reuse the already drawn elements the whole time while scrolling.
Just redraw the absolutely needed elements inside the already drawn div’s.
Now this is quite advanced, and maybe you don’t need to go that far. But learning the basics of how the DOM affects performance, and know strategies to better the situation, will be well worth your time.
I don’t know enough about dev regarding how anyone else would logically set up a timeline. Maybe there’s a trick to it.
I’m using set pixels, and the structure of the component is actually just state: active (bg_color) for “less work”.
I was wondering if I could do some sort of horizontal scroll loading which will work when “editing the timeline”. The case you made above with redrawing is more advanced that what i thought of, but very interesting.
… But a bit of the point is to be able to see a big picture of the whole thing. Which in some point will mean zooming out the the view to show all blocks. And that will be heavy again. I have been playing with the thought of using single divs with % sizes instead for using components. Might be able to reduce the components rendered.
Since i know the size of a column (32px), i can for each row push an object using margin-left on (days between start_date and item.date) * 32px.
It does significantly reduce the number of elements created, since its now only number of day columns (with divs) and div per row. Might be on to something?
For the lines between each row/column you are probably using a outline on your div. I’m instead using a repeating background in the wrapper to achieve that without creating additional DOM.
If you then combined this with moving the DIV’s around you could make the calendar scroll horizontal for years back and forth, without any lag.
And yea, this complicates fast. In my opinion It’s one of the biggest problems Weweb needs to solve in a nocode way, to make it easy for users.
For the columns, I am kind of bound to having the days between for now. I’m spitting out days between “parent” start_date and end_date in an array using js.
Got the “timeline” element as well, just multiplying 32px on the number of “timeline days” again.
It’s a lot more complicated to work with, but it seems to do the trick.
I guess my next step would be to wrap the whole thing into a component, so that i can set the timeline pixel width as a variable, effectivly controlling the “zoom level” on all objects.
And to what you said:
And yea, this complicates fast.
Yes. Chances are I might ruin the UX because of this.
Yes, weweb’s components are really powerful, so I would absolutely be wrapping this in a component. Then you can have formulas or workflows doing the calculations within the components itself, and component variables instead of global variables. Makes it much easier to maintain and keep things separate when your project grows.
For what it’s worth, I normally start with creating the concept way too advanced and complicated. Then Iiterate on simplifying everything with reusable workflows and components until it’s a simple and easy to maintain structure in the end.
