custom HTTP headers for network images

[charlesxsh]

Description

Allow users to pass custom HTTP headers when accessing network images.

Related Issues

• Related #1243

Type of Change

• [x] ✨ New feature: Adds new functionality without breaking existing features.
• [ ] 🛠️ Bug fix: Resolves an issue without altering current behavior.
• [ ] 🧹 Code refactor: Code restructuring that does not affect behavior.
• [ ] ❌ Breaking change: Alters existing functionality and requires updates.
• [ ] 🧪 Tests: Adds new tests or modifies existing tests.
• [ ] 📝 Documentation: Updates or additions to documentation.
• [ ] 🗑️ Chore: Routine tasks, or maintenance.
• [ ] ✅ Build configuration change: Changes to build or deploy processes.

Suggestions

[EchoEllet]

Thank you for your contribution.

You can use imageProviderBuilder instead to check if it's a network image and then pass the headers from there.

This new property will be ignored if users are using imageProviderBuilder.

I prefer not to add too many properties to pass them somewhere else.

[charlesxsh]

Thank you for your contribution.

You can use imageProviderBuilder instead to check if it's a network image and then pass the headers from there.

This new property will be ignored if users are using imageProviderBuilder.

I prefer not to add too many properties to pass them somewhere else.

I agree that not adding too many properties is the right way. But in this quite common & important usecase, this is relatively impratical. That was my initial thinking, using imageProviderBuilder. And then I noticed that, I have to cover all the other situations in imageProviderBuilder (Memory, Asset, File, etc..) if I use it, which is quite inconvenient (All the other handlers/functions for different image are not accessible from outside pacakge).

if (imageProviderBuilder != null) {
    return imageProviderBuilder(context, imageSource);
}
// rest of memory, asset, file will be ignored.

But what we want is simply add headers to network image.

[EchoEllet]

But in this quite common & important usecase, this is relatively impratical.

We currently have more important issues and should prioritize them over new features.

That was my initial thinking, using imageProviderBuilder. And then I noticed that, I have to cover all the other situations in imageProviderBuilder (Memory, Asset, File, etc..) if I use it, which is quite inconvenient (All the other handlers/functions for different image are not accessible from outside pacakge).

There is another way around this. We could make the return type of imageProviderBuilder nullable, and fallback to our default handling if the default value is null. There are other ways as well.

Similar to customVideoBuilder (see 10.8.0).

[charlesxsh]

If that case, I agree and this PR can be dropped.

[EchoEllet]

This issue has been fixed in release/v11 branch.

See the related migration change or image assets within release/v11 branch.

[EchoEllet]

Published a pre-release fixing this issue (#2338):

flutter_quill: ^11.0.0-dev.1
flutter_quill_extensions: ^11.0.0-dev.1