SebinSong
commented
2 weeks ago @taoeffect
There is actually a lot more things to improve in this project. (Which I didn't get to touch as that might lead to causing another bug)
Firstly, The entire app is actually rendered as animation if you see this line of the original code, even when there is no visible animation going in the content. My guess is that, Ian originally had some webGL animation for this app and then removed it later on but then didn't get to cleanly delete all the animation-related code as it's too giant. This should be entirely removed.
Secondly, I kept wishing this app was a Vue app while working on this source-code. This app is essentially an app whose UI updates are driven by the state changes (e.g. group-size changes -> more banners are displayed.). Also, there is a lot of UI elements that are created as a raw html string with a bunch of inline styles and then injected to the DOM(e.g. here). I wished they were a reusable Vue component. that would make it a lot easier to maintain this app.
Thirdly, tooltips are rendered inside a separate layer from the UI component that triggers it.
Normally tooltip for a certain component exists either as a sibling or a parent element because it's easier to show/hide it that way. But what this app does
when mouse-click happens is, 1) check mouse x, y coordinate 2) check if there's something underneath that position 3) decide/create the content of the tooltip on the fly and inject it the separate layer using position:absolute and top: n, y: n.
This makes it very really hard to maintain them.
Last but not least, there is no SASS and JS module system.
and so on...
For better further development, I think converting this entire source-code into 'AstroJS/Vue' project would help. If you agree with these too, pls create an issue and assign me to it. I can work on it in the future when GroupIncome project becomes less busy.
Cheers,
closes #1
[ From ]
[ To ]
[ Summary of work ]
As you can see from the screenshot attached, I actually worked on reducing the size of the footer as well, as part of fixing the problem (Thought there's no need for it too take that large space of the mobile screen).
Also, the original app paints the content in a confined space (which is 100% viewport height - toolbar - footer) and that forces the banner UI to become extremely small as the group size become larger. This actually made me think, "why not using scrollbar?". So I added a fix where the app uses scrollbar when the content area start to become crowded.