flutter-quill custom HTTP headers for network images

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

Oct 15 '24 04:10 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.

Oct 15 '24 12:10 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.

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.

Oct 15 '24 17:10 charlesxsh

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).

Oct 15 '24 18:10 EchoEllet

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

Oct 15 '24 18:10 charlesxsh

This issue has been fixed in release/v11 branch.

Oct 23 '24 16:10 EchoEllet

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

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

Oct 27 '24 15:10 EchoEllet