Skip to content
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

Allow setting options per directive instance. #70

Open
twwwt opened this issue Feb 27, 2017 · 4 comments
Open

Allow setting options per directive instance. #70

twwwt opened this issue Feb 27, 2017 · 4 comments

Comments

@twwwt
Copy link

twwwt commented Feb 27, 2017

Currently, one can configure options for the Marked renderer globally only using the markedProvider. It would be great if it would be possible, as an alternative, to provide options per directive instance.

Something like:

<div marked="my_markdown" marked-options="expression">
</div>

where expression is an Angular expression that evaluates to a Marked options object. For instance, it could be a reference to some property defined in some (parent) scope:

<div marked="my_markdown" marked-options="foo">
</div>
$scope.foo = {
   gfm: true
};
@TiboQc
Copy link

TiboQc commented Apr 7, 2017

Actually, using the service, you can add options on the fly: marked(text, options).
So you can use the scope to use render the markdown.

<div ng-bind-html="htmlContent"></div>
$scope.htmlContent = marked($scope.markdownContent, $scope.options);

This also allows to override temporarily the renderer, so you can do things such as changing the way headings are rendered or make advanced custom dynamic content wherever you want without impacting other markdown editors in your app like so:

var customRenderer = new marked.Renderer();
customRenderer.heading = function (text, level) {
    return 'Title ' + level + ': ' + text; // renders Title 1: <text> instead of using <h1> tags
}
$scope.htmlContent = marked(markdownContent, {renderer: customRenderer});

And you won't loose the other options, it only overrides the ones provided to the service.

@twwwt
Copy link
Author

twwwt commented Apr 7, 2017

Im concerned about performance implications of the solution proposed. If I'm not wrong about how ng-bind-html works, htmlContent, since it is a function, would be invoked on each digest cycle, no matter whether the markdownContent is actually dirty (i.e. has changed relative to the previous digest cycle).

@TiboQc
Copy link

TiboQc commented Apr 7, 2017

htmlContent is not a function, it's a model attribute. So it is only re-evaluated when needed.

Just to make sure, I tested it with both marked="htmlContent" and ng-bind-html="htmlContent" and putting a breakpoint in the marked renderer, and it is not called when I change other models in the view.
I even tried adding tons of markdown to the point where each keystroke in the markdown is slow to render, but changing another model in the view is pretty fast.

However, ng-bind-html is slower to render than using marked, but not by much. The difference started to be visible with very long markdown content containing many different styles (about a quarter second delay in rendering 145 000 characters).

EDIT: BTW, what I did is having the textarea bound to content and an ng-change that calls the marked service (with my custom options and renderer), setting its result to htmlContent.

@twwwt
Copy link
Author

twwwt commented Apr 7, 2017

Never mind. I was blind about the fact that the result of a function call is assigned (which is not a function itself) rather than the function called.

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

No branches or pull requests

2 participants