I think it would be great to have a small topic where we can tag each other to ask for PR reviews, so here it is
There is an increasing number of PRs, and I donât think I can review them all myself. To prevent PRs from being left unanswered, it would be great if we could help each other with the reviews!
Currently, there are a few PRs that need to be reviewed.
To review the code, itâs simple: I read all the code and see if anything shocks me in terms of pure code quality. Variable naming, etcâŠ
In short, read the code as if you were the developer of the PR, and ask yourself if you would have done it that way. If certain things shock you, add comments to ask for additional information, and if it really doesnât work, add a comment and mark the review as « Changes requested ».
Avoid being aggressive/degrading in the comments, the goal is to be positive: we just want to move the PR forward and have the maximum code quality
Functional Review
When I review a PR, I pull the PR branch by following the commands provided by GitHub:
Then I test everything absolutely: I try to break the integration by doing everything a user would do: enter, exit, re-enter, open the same page many times, to make sure it doesnât break.
After reading the code, I usually know a bit what will break: For example, many integrations have « scan » pages of devices. I want to make sure these pages do not launch a scan every time the page is loaded, otherwise if the user enters the page 10 times and there are 10 network scans in parallel, itâs heavy ^^ When there is a scan page, in my tests I open the scan page 10 times in 10 different tabs and see what happens (And often, it breaks aha)
Thanks to everyone who will help me review PRs, itâs also positive to do PR reviews as it is to make PRs
Following an initial review with @Tlse-vins, we noticed that some conditions were not tested for for each loops after queries. We resolved the issue, so I will need to do a new push. How does it work when the PR is under review? Do I need to request a review again? Or is there nothing more to do?
Could someone help me⊠I have a normal eslint error⊠but I donât know how to fix it. So you will surely tell me a noob question. But I must not be good at searching because I canât find the answer. I created a function to fix the repetition remark from @AlexTrovato in the Netatmo PR. However, one of the input parameters (newValue) can be a {number} or a {boolean}. So I didnât specify anything in @param. It works fine but eslint gives me an error. Is there a way to disable eslint on this or to specify multiple data types for a param. I tried several things, but nothing works. Thanks in advance
Edit: itâs okay I found it ^^ I didnât push far enough ^^ In case other people are looking, I leave my post and the link to the doc on this point: https://eslint.org/docs/2.0.0/rules/valid-jsdoc
I did complete tests of this last one on the FR side and removed EN, trying some slightly buggy stuff (a bit of a mess) and as long as it makes sense, it works well for me. The display of days instead of the time is good. However, the days are displayed in English despite the FR interface. I therefore recommend the following changes to take into account the FR language:
In the file front/src/config/i18n/fr.json - line 17 after "save": "Enregistrer" - add:
Finally, take advantage of this PR to fix the small bug of the wind unit display which in metric unit gives miles/hour instead of km/h: . Replace in the file front/src/components/boxs/weather/WeatherBox.jsx also - line 179:
{props.units === 'si' ? 'km/h' : 'm/h'}
with (a small console.log allows us to see that props.units returns either âč metric âș or âč âș) by adding a space to the units to make it prettier:
{props.units === 'metric' ? ' km/h' : ' m/h'}
Functional for me:
Hopefully, I have been helpful. Iâm moving on to the other PR
Best regards, Thomas.
Scenes are created for testing. Now we just have to wait.
However, I already have a comment. It is not specified anywhere what needs to be configured in advance to benefit from this scene. Maybe if the house coordinates (I assume thatâs the only condition) are not provided, a warning message would be welcome in the trigger box - especially since there is room:
@pierre-gilles:
When testing a long house name, I was able to identify a « bug ». When you enter a long name, here âč Maison Test Sunrise-Sunset sans Emplacement âș, the UI returns an error that is not appropriate when saving:
Hi @Terdious! Thanks for your reviews, next time try to do the review directly on Github, itâs made for that and itâs easier than going back and forth with the forum
For the PR about the weather, I think you only tested the tip of the iceberg, the bulk of the PR was on the « discussion with Gladys » part, there are dozens of new sentences that have been added, and they need to be tested one by one, and checked that they all work. At my last test, that wasnât the case but normally there have been improvements since!
For the PR about the sun, good remarks. Itâs still better when the remarks are put on the PR
For that, the problem is that I donât see the request I made in the changes commits page. Therefore, I couldnât review the files in question directly on Github. But I left the link to the gladys community
because I thought that given the length of the post, it would be a bit of pollution on the github thread. However, not knowing the github review practices well yet, if itâs preferable, I will make sure to apply that next time
Plus the whole response part. So indeed, I couldnât test everything because I donât have snow forecast. But for the rest, everything was functional for all the days of the week, tomorrow and the day after tomorrow; and for all types of questions I did the tests with and without accent, with extra spaces between two, with small typos (ex.: « Donn moi la meteo » or « Donne le meteo ») and all the returns were as expected. For the part I couldnât test (the snow), I read the code to see if it was like the rest tested. I didnât see anything in particular.
Let me know especially if my methodology is not the right one, or if there are additional things I should get used to doing more. If I can help more by doing it right, it will be a pleasure.
Thatâs good news, the update must have done a lot. (Accents, typos, âŠ)
I made sure the questions were the same for everyone, so if it works for rain, it will work for snow.
This is not pollution, on the contrary. Everything related to PR reviews should be in GitHub; itâs much easier for the developer to take your feedback one by one and address them.
When you do a review, start a review, and leave comments in the code where you think there are issues:
Itâs simpler for everyone if we use GitHubâs mechanisms
Great! Good news then
Thanks for the tests, in terms of methodology, it was good. You just need to put yourself in the userâs shoes and test everything from A to Z, and make sure everything works as expected.