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
[add] Image source headers handling #11
[add] Image source headers handling #11
Changes from 3 commits
059ab04
4e6daca
8f4d952
1e54c64
93df02a
7353183
bb25c15
1f393c4
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.
I've tried to write some unit tests covering the new functionality, but because of this logic a few mocks need to be setup and make the PR bigger than it has to be
I think it might be better to move this logic to
ImageLoader.loadUsingHeaders
so in unit tests we can stub that method and ensure it gets called when we intent toIt's easy to manually verify the
fetch
logic works and downloads contentOnce that's clear it's easy to just verify
loadUsingHeaders
is called correctly with expected inputI've made a similar comment on the main repo: https://github.com/necolas/react-native-web/pull/2442/files#r1072080652
What do you think, should we refactor / write some tests now or let the mainstream repo request those changes?
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.
Hmm since this logic is the real meat & potatoes of the
ImageWithHeaders
component, if we move it toImageLoader.loadUsingHeaders
I assume we could get rid of thisImageWithHeaders
component, and basically check if there's headers passed in the props - if yes, we callImageLoader.loadUsingHeaders
instead ofImageLoader.load
here?react-native-web/packages/react-native-web/src/exports/Image/index.js
Lines 269 to 294 in bd1f7b8
If that's what you're thinking, I honestly do think that logic is cleaner, even without needing to write tests for Expensify's case so I'd say the refactor sounds like a nice idea
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.
Well, the idea is purely to ease mocking but I'll give your suggestion a try
Last PR tried to solve everything inside the same component but that resulted in more logic
What a component like
ImageWithHeaders
gives us is a guarantee thatsource
would always be an object with headersBTW there's feedback on the mainstream PR: necolas#2442 (comment) that we should write tests and thumbs up for extracting
ImageLoader.loadUsingHeaders
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.
I've tried to remove the
ImageWithHeaders
component and use eitherloadUsingHeaders
orload
functions here: https://github.com/Expensify/react-native-web/compare/master...kidroca:react-native-web:kidroca/feat/image-loader-headers-alt-2?diff=unifiedBut it results in a similar amount of changes and modifies some of the original logic (and seems harder to review)
useEffect
needs to account for objectsload
andloadWithHeaders
need to work in a similar way in order to be interchangeable (so they were modified to return arequest.cancel
function)We might merge
load
andloadUsingHeaders
instead of testing which one to run, though this would be similar to the first PR wereload
handled loading images with and without headersThere 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.
Thanks for doing that refactor! Personally I prefer the new changes because it keeps all the image loading logic in
ImageLoader
and there's minimal changes toImage/index.js
- I don't see those new changes too difficult to review (though I am not sure wherelastLoadedSource
gets updated).I'd say let's move forward with this last refactor, as I think it's pretty straightforward compared to passing / not passing specific props to the BaseImage component required in this PR
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.
IMO the refactor is more of a proof that there are more "gymnastics" necessary in order to make this work by changing the original logic inside Image component
Original logic is changed, the cleanup logic is different,
ImageLoader.load
is changed, people, including the mainstream maintainer would have to inspect how these used to work and whether the change is suitableIMO the mainstream maintainer already saw the update and is fine with just moving the
fetch
call toImageLoader.loadUsingHeaders
. I'm still trying different things, but the most straightforward PR so far seems to be the current oneThere's also a big rework planned for the Image and the original loading logic would change, it would probably be best to not write stuff that depend on it (in the alt branch
loadUsingHeaders
depends onload
)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.
Let me update the current PR with
loadUsingHeaders
extracted toImageLoader
and then we can make one final decision which set of changes would work best for usThere 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.
Yeah this is one additional reason I really like this approach, even though there may be some additional changes in the upstream repo needed that we don't need at the moment in this fork 👍
That sounds perfect, thanks so much @kidroca 👍
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.
Not too sure what this comment means. Is there a different way to say this?
I think it's something like - the
BaseImage
onLoadStart
event is not exposed to the parent. We are only interested in when the source with headers starts loading and not when theBaseImage
loading starts?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.
I think it's more like:
ImageWithHeaders
already callsonLoadStart
when it starts loading the image, so we don't want theBaseImage
to trigger that function a second timeThere 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.
Now that I look at it I see it's confusing - it's like Alex said - loading starts inside
ImageWithHeaders
, to preventBaseImage
to raiseonLoadStart
a second time we filter it outThere 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.
Ok cool I think we are all saying the same thing -
BaseImage
will not use anonLoadStart
callback when we have headers.