Stop build header and the build log stutter
When I was working on the dashboard of the project, I regconize that our dashboard sending too many request in such a short time and when using it and it make the UI stutterbut at that time I did not practice the habbit to filling issue yet so when I was fixing the loading animation in the build header I just kind to ignored it. When our proffessor bring up the issue, I was happy to tackle the issue. At first what I did was to check the interval and see how frequently our build information got requested and rendered. It is 5 seconds beetween each time we send the request to the autodeployment server. I regconize our build on master usually took average from 3-5 minutes to finish. So I went and made a dummy change which is to extend the interval beetween each call to 1 minute. It work but after revise the issue description it is not that optimal yet. My next move would be finding a way to extract the text from the xterm terminal and compare with the upcoming data that about to be written in the terminal. I kinda form a routine where I force myself to look at the docs first instead of straight up searching things on stackoverflow. I spent 2 days on Xterm docs trying most of the available methods and properties provided from Xterm. The doc was not that good since it did not give any usage. After trying onData, onRender, terminal.selectAll(), etc,... . I then search for stackoverflow and regconize that did not provide a way to retrieve the content of the terminal with the public API, I also would think compare such a long string of text will be time consuming and not that efficient. I have to change my way on how I think about it. I decide to tackle the build which contain sha which is unique to each build. But I have to use the global scope variable which is not a good practice. I decided to pushed and make a PR to update with the team and also learn how they would solve it different than what I did.
In general I agree with you: fewer variables, reduce their scope. But this is hard to avoid completely.
I will say we try to avoid it as much a possible but it not that bad to use after all if we can not avoid it.
Indicate better build information in build-header
For me this PR is not that bad and not exploring much since I already got some experience working on the dashboard so I just need to search for bootstrap docs and read about truncate text using eslipsis. You can checkout my PR
Review and practice a habbit to file issue
So far, I being less active on filling issue on the project which I should since it is a good things cause shipping software is an endless job. Next version of the software will hopefully be better than the previous version and we always try to make the software more complete for the users. So I file 2 issues on the Telescope about bugs and enhancement needed it in the dashboard where the dashboard not showing up build in production which lead to another disscussion where we should use supabase to keep our dashboard being more consistent. Finally, I start to create more "trouble" for the whole team to tackle :)).
I also got 3 pr that needed to coming up but Jerry was one step ahead. So I help Andre to review the PR. I just want to talk a bit more a bout how I tackle this since I'm feeling like I'm getting more comfortable working and tackle new issue. Andrew suggest us to look at the utils\toast.js and after take a look at it I'm using search to find it usage accross the project and found enough information for myself to tackle the problem.
For 2.8, I have been reading and learning a bit about docker and superbase and hope to jump on any 5 min fix issues to learn more about it by doing
Top comments (0)