[dont merge] - Refactor proxy client & migrate issue screen #770
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.
Description
Hi team,
I've started looking at Step 4 of #761 (handle put/patch/delete) and experimented on the Issue screen.
While doing that, I came to the conclusion that the Proxy <=> Client interactions needed to be changed a bit, in order to give the proxy more power over all kinds of operations, and how the resulting data is reduced in store.
As a result, the client/proxy code is way clearer than before 🎉
You can follow the train of thought that lead to this PR in this gist, and I really encourage you to do so in order to completely understand this Proxy thing: https://gist.github.com/machour/698e91e075ac35ad64531d03c80a99bf
If you pull this PR and test it locally, you will see the following stuff:
POST
call is triggered, and its result is automatically appended to the list of comments (without refetching)PATCH
call is triggered, and the changed fields are automatically updated in store (without refetching)DELETE
call is triggered, and the comment reference is removed from the comments list in store (again, no refetching)PUT
call is triggered, and the Issue object we already have in store is patched so that thelocked
property is up to date (instead of re-fetching the whole issue).Same thing goes for issue labels and assignees.
To say thing differently: Our Store is 100% up to date with GitHub, by doing precisely what needs to be done. Nothing more. Nothing less.
This PR won't be merged as a whole.
Instead, I'll be opening a smaller PR with the subset of changes needed for the refactoring so that we can confirm that everything still work without touching the migrated screens code.
Once this first PR is merged, I'll open a new one to unleash the PUT/DELETE/PATCH/POST features.
I've already did a 1 on 1 with @housseindjirdeh to walk him through this PR, and I'll be happy to do this with any of you girls and guys!