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.

Sign up for GitHub

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

Jump to bottom

wishlist: Explore applicability to DOM creation #39

Open
chrysn opened this issue Apr 29, 2020 · 3 comments
Open

wishlist: Explore applicability to DOM creation #39

chrysn opened this issue Apr 29, 2020 · 3 comments

Comments

@chrysn
Copy link

chrysn commented Apr 29, 2020

The data structure created by horrorshow might easily be suitable to create a DOM from it as well, in parallel to serialization to text-encoded HTML. Some features of horrorshow might be unsupported (I'm unsure as to how much raw text can be used with modern DOM APIs), but that might be acceptable for use cases.

The typed-html crate provides something some steps in that direction (I haven't seen an example of actual shared HTML, but it can be used to render either to HTML or to dodrio), but is not actively maintained any more, and horrorshow's syntax seems nicer to me.

The application I see for it would be to use the same code to render things server side, but (with a vastly different backend) to also perform client-side updates from WASM.

There was one previous issue in that direction (#29) where DOM was described as out-of-scope, so this is more about exploring DOM creation based on horrorshow, for which I'd like to gather input here:

  • Has creating a DOM from RenderOnce objects been attempted?
  • Are there any major known showstoppers?
  • Would the project be open to (possibly under a feature flag) exposing internals that would allow other crates to implement DOM rendering based on horrorshow's templates? (I'm far from understanding its internals yet, but that could for example be a trait around TemplateBuffer that can be implemented by a DOM builder.)
@Stebalien
Copy link
Owner

Horrowshow is built entirely around text manipulation so this will be tricky. But I'm open to patches as long as:

  1. It's optional. Horrorshow can work without std/allocations and I'd like to preserve that.
  2. It doesn't impact performance when rendering to a string.

Main show stoppers:

  • Everything is text-based.
  • Keeping performance with a dom-based version may not be possible.
  • Preserving write_raw and friends is probably impossible.

If you want to try this, I'd suggest creating a fork and seeing where you get. You're probably going to have to re-write everything.

@chrysn
Copy link
Author

chrysn commented May 6, 2020

After some experimentation, cargo +nightly rustc --profile=check -- -Zunstable-options --pretty=expanded on an example probably illustrates best what you meant by everything being text based:

            |__tmpl: &mut ::horrorshow::TemplateBuffer| -> ()
                {
                    __tmpl.write_raw("<body><h1 id=\"");
                    ::horrorshow::RenderOnce::render_once("heading", __tmpl);
[...]
                    __tmpl.write_raw("</p>");
                    __tmpl.write_raw("</body>");

I'd still like to explore the possibility, but this shows clearly that compatibility between horrorshow rendering text and anything horrorshow-like rendering a DOM would need to use different preprocessor expansions, which puts it more in the league of "compatibility" rather than "being generic".

@Stebalien
Copy link
Owner

Yeah, I'd expect any DOM based version to effectively be an alternative implementation of horrorshow with a compatible API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Stebalien @chrysn