Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
[TM-1531] add job connection #745
base: staging
Are you sure you want to change the base?
[TM-1531] add job connection #745
Changes from 11 commits
aa5b7e6
153050a
fa4d2c4
9fbece2
8303877
06783b3
4972958
e8cef37
ded0b85
c8d7c71
07e2d56
9d45753
05fdae6
4637c98
e58c0a1
996d5a7
b6e0102
fc1a52a
69d08d7
d5ba353
042ecbc
06a7958
6cad9a9
af9b8da
1b73259
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will cause this interval to keep refreshing the delayed jobs for as long as the surrounding component is mounted. Is that intentional? It seems like clearing the interval when all the delayed jobs have completed would be good to keep from continuing to hit the jobs endpoint. I'm OK with letting this live to prod if that's complicated to wire up; it's just not ideal and should be cleaned up in a future ticket.
Please either decide to implement an eventual stop like that in this PR, or see that a tech debt ticket is created to clean up in a future release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes indeed, it is supposed to be attentive for any job created on any session.
Nonetheless I think it might not be good.
So for now the debt ticket will be needed, because we would have to think on the user cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the component using this hook expected to be mounted a lot of the time, or does the user have to go to a specific view for it? If this is up all the time, then I think we need to consider a better approach. If it's a view that's only mounted when the user is actively watching for something to finish, then I think this OK for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should use
??
for defaults, although I think this is an overall better format for this method:However, I'm also confused as to why you would expect a
response
object to be onstore.delayedJobs
. That shouldn't be possible with the current redux setup.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the response object wasnt needed, and everything keeps working.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like it should be throwing an error in the TS compiler... Maybe I'm missing something, but this shape does not seem to match
DelayedJobsConnection
.A couple of thoughts here:
isLoading
,hasLoadFailed
andresponse
, while seeming convenient when looking at a single connection, are actually a disaster down the road. The reason being that if we follow such generic conventions for individual connections, then when a component ends up using 2 or more connections, it gets really awkward to juggle all theisLoading
s that each connection returns. Instead, I think it's better to be super specific with the properties of the connection shape. So something more likebulkUpdateJobsIsLoading
andbulkUpdateJobsHasFailed
.As for
response
- this appears to be just returning all the delayed jobs like the other connection does. Are these used in the same component? Perhaps a better approach would be to combine them into a single connection. I think of connections as being responsible for providing a given set of data from the redux cache, and a set of functions for operating on that data. It would be totally reasonable for thisbulkUpdateJobs
call to be triggered from a function that's included on the other connection. Or, the bulkUpdate function could be simply exposed by this file, and then we simply rely on the original connection to provide thedelayedJobs
from the store. One of the primary wins of this system is that a connection returns data that got cached in the store regardless of where it came from. So if one call does the initial fetch, and another call modifies that data, as long as the data ends up back in the store under the same ID, the component that relies on it will rerender when it gets updated.