Here is my PR for modularization, largely based off the written proposal in #645. Includes all changes from #632, but that should be merged first, and a release should be created with those changes.

Fixes #323, fixes #442.

Changes

• Created packages:
  • flutter_html_all - convenience package that exports all other packages
  • flutter_html_audio - provides audio tag, uses chewie_audio and video_player
  • flutter_html_iframe - provides iframe tag, uses webview_flutter
  • flutter_html_math - provides math tag, uses flutter_math_fork
  • flutter_html_svg - provides svg tag & svg image, uses flutter_svg
  • flutter_html_table - provides table tag, uses flutter_layout_grid
  • flutter_html_video - provides video tag, uses chewie and video_player
• Core package dependencies reduced to html, csslib, collection 🎉
• Removed customImageRender and merged with customRender since it basically provides the same effect
• Removed navigationDelegateForIframe, it can now be set via a parameter in the iframeRender() CustomRender
• Removed onMathError, it can now be set via a parameter in the mathRender() CustomRender

Pending (complete in order)

• Change external CustomRenders into functions to keep things consistent with default renders in the "core" library
• Update docs
• Check example app for any regressions
• Publish updated version of flutter_html with customRender changes
• Change path dependencies to versioned dependencies
• Publish new packages

Example

Let's say the user wants to have the full-fat flutter_html experience with support for all the tags. With this PR, it would look like this:

pubspec.yaml

flutter_html: ^latest
flutter_html_all: ^latest

.dart

Html(
  data: htmlData,
  customRenders: {
    tableMatcher(): CustomRender.fromWidget(widget: (context, buildChildren) => SingleChildScrollView(
      scrollDirection: Axis.horizontal,
      child: tableRender.widget!.call(context, buildChildren),
    )),
    audioMatcher(): audioRender(),
    iframeMatcher(): iframeRender(/*optionally provide NavigationDelegate here*/),
    mathMatcher(): mathRender(),
    svgTagMatcher(): svgTagRender(),
    svgDataUriMatcher(): svgDataImageRender(),
    svgAssetUriMatcher(): svgAssetImageRender(),
    svgNetworkSourceMatcher(): svgNetworkImageRender(),
    videoMatcher(): videoRender(),
  },
),

Debates

1. Should we remove customImageRender? I made those changes in a separate commit to make it easily revertable if we decide this. Personally I see no reason for it now, but I could be swayed against this change.
2. Should we provide a Map<CustomRenderMatcher, CustomRender> in the flutter_html_all package? Rather than the user having to do the above, they could simply do customRenders: allRenders or something like that.