-
Notifications
You must be signed in to change notification settings - Fork 19
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
wishlist: Explore applicability to DOM creation #39
Comments
Horrowshow is built entirely around text manipulation so this will be tricky. But I'm open to patches as long as:
Main show stoppers:
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. |
After some experimentation, |__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". |
Yeah, I'd expect any DOM based version to effectively be an alternative implementation of horrorshow with a compatible API. |
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:
The text was updated successfully, but these errors were encountered: