-
Notifications
You must be signed in to change notification settings - Fork 203
Convert existing comments to be statically rendered. #3295
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Here's how comments currently work: For an issue, initialize the
If there are any comments on the issue, here is where we fetch them: webcompat.com/webcompat/static/js/lib/issues.js Lines 368 to 396 in 357e053
Then if there's more than 30 comments (super rare, I would imagine), grab the rest: webcompat.com/webcompat/static/js/lib/issues.js Lines 398 to 415 in 357e053
This is where we render an individual comment (this gets called for each existing comment, and for new comments): webcompat.com/webcompat/static/js/lib/issues.js Lines 417 to 430 in 357e053
|
Maybe a place to start here is to create the ability to fetch 30 pre-rendered comments at a time, returned as HTML we can add to the page after the initial load. I'd like to avoid building 2 entirely different comment loading solutions, where possible (because they're likely to fall out of sync). I don't think it's entirely unavoidable, but something to aim for. |
Or at least, the first 100. Future work will make sure we get all of it.
Or at least, the first 100. Future work will make sure we get all of it.
Or at least, the first 100. Future work will make sure we get all of it.
Or at least, the first 100. Future work will make sure we get all of it.
We can get rid of the clientside handling of all of this now.
It's no longer to test this the way that we did. We'll have to rely on mocked unit tests (which is fine, this just tested that some data was injected to the frontend, it never tested if it worked on the GitHub side of things)
We can get rid of the clientside handling of all of this now.
It's no longer to test this the way that we did. We'll have to rely on mocked unit tests (which is fine, this just tested that some data was injected to the frontend, it never tested if it worked on the GitHub side of things)
We can get rid of the clientside handling of all of this now.
It's no longer to test this the way that we did. We'll have to rely on mocked unit tests (which is fine, this just tested that some data was injected to the frontend, it never tested if it worked on the GitHub side of things)
We can get rid of the clientside handling of all of this now.
This file will be returned when POSTing a new comment in test mode, so our existing functional tests can pass. When doing a GET, it will serve /tests/fixtures/api/issues/100/comments.38e6a9ddcea3ef150105b48bcd1c18f3.json because it has a ?per_page=100 param.
Now we rely on everything coming back from GitHub before rendering, so there's no more need for this.
Co-authored-by: Karl Dubost <[email protected]>
Co-authored-by: Karl Dubost <[email protected]>
Co-authored-by: Karl Dubost <[email protected]>
Or at least, the first 100. Future work will make sure we get all of it.
We can get rid of the clientside handling of all of this now.
This file will be returned when POSTing a new comment in test mode, so our existing functional tests can pass. When doing a GET, it will serve /tests/fixtures/api/issues/100/comments.38e6a9ddcea3ef150105b48bcd1c18f3.json because it has a ?per_page=100 param.
…st and api_request
Now we rely on everything coming back from GitHub before rendering, so there's no more need for this.
Co-authored-by: Karl Dubost <[email protected]>
Follow up to #3281
This may or may not be desirable, since it will require us to block on another request. Perhaps dynamic is the way to go here. 🤔
But if we want to create an archive, we will at least need a method that allows for static comment rendering, so it could be optional.
The text was updated successfully, but these errors were encountered: