-
|
Hi, lets say we have index.html file and inside of the file we have bunch of components. Is there a way to access them in Leptos?For example by id of the component etc. <!DOCTYPE html>
<html>
<body>
<h1>Welcome</h1>
<button>This is a fine button</button>
</body>
</html>Is there a way to access this button from Leptos and add some functionality? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 6 replies
-
|
Yes and no. It is entirely possible to work with any old DOM element using the tools provided by Like any framework, Leptos works primarily by adding functionality to element that it creates. So we'd tend to think about mounting a Leptos application to a particular DOM element, rather than using Leptos to add some functionality to an existing DOM element. You'd do this by using It is also possible to just use some of the helper utilities included in Leptos to add an event listener or something to an existing button, but the lower level you go like this the less the framework is helpful. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @gbj , I have 2 ideas. 1- First class support for accessing and utilizing with raw HTML files. For achieving more success in SEO optimization and reducing WASM penalty for this situation, these two ideas may help to us. As much as HTML we provide search engines will like us more. I'm sure you know details more than me. Raw HTML accessing and compile time check for existence of the used element in Leptos would be a chef's kiss. Like sqlx, Askama and other macro based fellas. This will provide the power of Rust to Leptos more. Automatic HTML creation can also serve the same idea. Like how Svelte does and how React's trying to do with their compiler. Also these two features can increase code reusability of HTML with other frameworks and languages too. After all we can say, hey we can use server side rendering to provide more optimized SEO and also you can get raw HTML from your browser, if you need to but there are people who just love more traditional and simple way to approach front-end. These ideas can increase power of client side rendering since we can't be fast than plain HTML by any possible means. Probably opening an issue as a feature request would be better but since I may not think situations more clearly than you I wanted to be sure if these ideas are logical or not. |
Beta Was this translation helpful? Give feedback.
-
|
I don't understand what you mean by "automatic HTML creation" here or how what you're describing differs from the existing support for server side rendering. (Here's an overview, if it's helpful.) For example:
Yes, this is true, and this is why Leptos has complete server-side rendering support. I can't tell whether 1) you know this and are talking about something else, or 2) you don't know about the existing SSR support. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for bad explanation. First one is about increasing support and developer experience about accessing some HTML file directly like my very first question. Also with a macro we can check weather our components are really exists or not. Relatively this:
With this kind of things raw HTML file integration can improve. Second one is about client side. Creating HTML on compile time based on Leptos syntax and pack them. Relatively this: I know SSR exists and what it does. I'm proposing first idea for both client and server side applications. I'm giving second idea to improve SEO performance of only client side applications by providing as much as static element as raw HTML. I hope this time I could explain myself much better :-D |
Beta Was this translation helpful? Give feedback.
-
This is something you should do quite rarely when using any declarative, component-based or view-based framework; once you start manually manipulating the DOM you lose most of the benefit of using a framework, and can very easily introduce bugs because your code and the framework's code might both be trying to update the same thing. I think it's totally reasonable to build a library to make it easier to import HTML files and then add small amounts of interactivity to them. It might even be a great idea! Leptos is not that library, but I would genuinely encourage you to work on doing this if you think it's a good idea. It sounds like it would be a pretty straightforward small project. I think your ideas here are good, they just do not fit well with the paradigm the rest of the framework is using.
You can do this with some of the static routing features we have (see the |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! and sorry for bothering :/ There is no problem with first one I understand you and you understand me and it's totaly fine. For second one I think I couldn't explained myself better. I'm not talking about serving static file but creating static file in compile time. We will going to write a Leptos component and a system will convert it's static parts to HTML file. Everything will be in compile time without SSR. So in the end we will have some HTML files that has static parts and a WASM file that has functional parts. This seperation will be automatic. It's for client side only projects. I hope this time I did it better :D |
Beta Was this translation helpful? Give feedback.
Yes and no.
It is entirely possible to work with any old DOM element using the tools provided by
web-sys, which provides a Rust interface for all DOM APIs. For example, can can easily candocument().get_element_by_id("...")to get access to an element.Like any framework, Leptos works primarily by adding functionality to element that it creates. So we'd tend to think about mounting a Leptos application to a particular DOM element, rather than using Leptos to add some functionality to an existing DOM element. You'd do this by using
mount_to(some_element)rather than the more generalmount_to_body(), and it's completely possible.It is also possible to just use some of the helper utilities …