Skip to content

Added support to skip custom render-er if is null #384

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

Merged
merged 3 commits into from
Jan 7, 2021
Merged

Added support to skip custom render-er if is null #384

merged 3 commits into from
Jan 7, 2021

Conversation

dev-kuma
Copy link
Contributor

These changes allow skipping the custom render-er and using back the default render-er in some cases,

by returning a null value or not returning any value from the function "customRender".

These changes allow skipping the custom render-er and using back the default render-er in some cases, 

by returning a null value or not returning any value from the function "customRender".
@erickok
Copy link
Contributor

erickok commented Aug 19, 2020

Could you give an example where this is useful?

@DFelten
Copy link
Contributor

DFelten commented Aug 19, 2020

Very useful feature. This is helpful for example when changing only elements with specific attributes. Currently it's only possible to add a custom renderer for whole tags. But with this change it could be possible to check specific attributes and only change the rendering when necessary.

An other example is an iframe. When it's a YouTube url I would like to show a custom YouTube player, and for other urls the normal WebView.

@dev-kuma
Copy link
Contributor Author

@DFelten Thank you! Indeed very clear clarification!

Could you give an example where this is useful?

Providing that there is some html I need to parse,

<!DOCTYPE html>
<html>
<body>
<!-- case 1: youtube video -->
<a href ="https://youtu.be/xxxxxxxx">https://youtu.be/xxxxxxxx</a>
<!-- case 2: simple link-->
<a href ="https://xxxxxxxx">https://xxxxxxxx/</a>
<!-- case 3: image inside link -->
<a href="https://xxxxxxxx"><img src="xxxxxxxx" /></a>
</body>
</html>

In current version of "flutter_html", setting the "customRender" like this,

customRender: {
  'a': (context, child, attributes, _) {
    if (attributes['href'].contains('youtu.be')) {
      // normal case
      return YoutubePlayer(...);
    } else {
      // problematic case
    }
  }
}

it will stop handling "simple link" or "image inside link" with default render-er,
even though return part is specifically omitted or set to null for these 2 cases.

Copy link
Contributor

@erickok erickok left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a great idea and almost correct but (perhaps due to upstream changes?) your code does not build. Extremely easy fix though as you just need to use child: customRenderForElement,.

newContext: newContext,
style: tree.style,
shrinkWrap: context.parser.shrinkWrap,
child: builder,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is incorrect. It needs to be

            child: customRenderForElement,

@ryan-berger
Copy link
Contributor

@erickok I believe that the changes you requested have been made, and things look good to me, but I just want to make sure you are fine with it as well before I merge

@erickok
Copy link
Contributor

erickok commented Jan 4, 2021

Yes, I applied them to this PR. I am using this in production.

Copy link
Contributor

@ryan-berger ryan-berger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@ryan-berger
Copy link
Contributor

@erickok it looks like you have to resolve the change request before I can merge

@erickok
Copy link
Contributor

erickok commented Jan 4, 2021

@ryan-berger done

@ryan-berger ryan-berger merged commit 0226739 into Sub6Resources:master Jan 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants