search

MyNihongo / MudBlazor.Markdown

Markdown component based on the MudBlazor environment
https://mudblazor.com/
MIT License
132 stars 13 forks source link

Feature Request: Extensible rendering #200

Closed MaxGuernseyIII closed 1 year ago

MaxGuernseyIII commented 1 year ago

Me, again.

It would also be useful to be able to extend this behavior:

https://github.com/MyNihongo/MudBlazor.Markdown/blob/e7ea150e6c08a17bb0c5cfb4dec7983c0473eecc/src/MudBlazor.Markdown/MudMarkdown.razor.cs#L140-L200

So that one can provide rendering logic for custom blocks we introduce with custom pipelines. As always, I'd be happy to do the necessary refactoring along with any other changes required in a PR, if you prefer.

MihailsKuzmins commented 1 year ago

Could you share your ideas why it does not satisfy your requirements? If you want to keep control of rendering you will need to reimplement your own RenderMarkdown.

Another approach could be inheriting from MudMarkdown, but it means all rendering methods need to be virtual (maybe, maybe not) and protected.

If you are all right with this implementation I do not really mind.

MaxGuernseyIII commented 1 year ago

I don't want to change how you render the standard stuff at all.

I want to be able to render custom block types not known to the switch statement.

I guess, looking more closely, there are other things I want to be able to extend, most importantly: the inlines.

MaxGuernseyIII commented 1 year ago

Virtual methods would be fine. I would prefer RenderFragment<T> parameters called from default branches of the switch statements. That would allow me to extend the markdown model and render the extended elements without inheriting from MudMarkdown.

MihailsKuzmins commented 1 year ago

I don't want to change how you render the standard stuff at all. I want to be able to render custom block types not known to the switch statement. I guess, looking more closely, there are other things I want to be able to extend, most importantly: the inlines.

So, coult you summarise what exaclty you want to be able to override? Only unknown case statements, RenderInlines() method, or unknown case statements within RenderInlines()?

Virtual methods would be fine. I would prefer RenderFragment parameters called from default branches of the switch statements. That would allow me to extend the markdown model and render the extended elements without inheriting from MudMarkdown.

I would like to avoid it. If we need more methods to override, having many parameters is not good. Alternatively it is possible to come up with something similar to MudMarkdownStyling which overrides styling.

MaxGuernseyIII commented 1 year ago

So, coult you summarise what exaclty you want to be able to override?

Yes, the two things I want to override would be unknown cases in RenderMarkdown() and RenderInlines().

I would like to avoid it. If we need more methods to override, having many parameters is not good.

I would argue that a composition-based approach is preferable to one that relies on inheritance but this is your codebase, not mine.

Alternatively it is possible to come up with something similar to MudMarkdownStyling which overrides styling.

I like the way you handle all the standard elements. I don't want to change it or style it at all. I just want to be able to render custom blocks and inlines.

Not that having a styling class is a bad idea. It just doesn't address the feature request I'm making, as I understand it.

MihailsKuzmins commented 1 year ago

I see, well. I will try to see what I can do. Probably I will try with the inheritance approach first.

MihailsKuzmins commented 1 year ago

I have added more customization to the markdown component. Before I release a new version (still need to fix one new issue), could you check whether it is what you need? You can either checkout the code and reference the project directly or I might prepare an RC package.

MaxGuernseyIII commented 1 year ago

Yes. That looks perfect.

-- Max

There are 10 kinds of people: those who don't understand binary, those who don't understand trinary, and so on...

On Sat, Sep 9, 2023, 8:57 PM MihailsKuzmins @.***> wrote:

I have added more customization to the markdown component. Before I release a new version (still need to fix one new issue), could you check whether it is what you need? You can either checkout the code and reference the project directly or I might prepare an RC package.

— Reply to this email directly, view it on GitHub https://github.com/MyNihongo/MudBlazor.Markdown/issues/200#issuecomment-1712702685, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC4DRFU2VYG4DIFPRYBINXDXZU3DZANCNFSM6AAAAAA33TIXAY . You are receiving this because you authored the thread.Message ID: @.***>