Replies: 1 comment 1 reply
-
VanJS positions itself as an unopinionated framework where people can choose from a procedural style or a declarative style of programming for each specific problem they're trying to solve. Thus the style of your code is definitely recommended. Alternatively, you can also build the app in a declarative style, like that: const Menu = () => {
const open = van.state(false)
return div({role: "menu"},
button({"aria-controls": "menu-content", "aria-expanded": open, onclick: () => open.val = !open.val},
"Menu",
),
div({id: "menu-content", role: "menuitem", hidden: "", "aria-hidden": () => !open.val},
ul(
li(a({href: "#"}, "Home")),
li(a({href: "#"}, "About")),
),
),
)
}
van.hydrate(document.querySelector('[role="menu"]'), Menu) A minor downside (most likely negligible) is a slight overhead at hydration time due to the re-rendering of the DOM tree for |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi There! First of all, thanks @Tao-VanJS for creating such a great library. I'm in a similar position and I almost created my own reactive framework that's similar in spirit to vanjs (i.e. I'm also a backend dev mainly, and I wanted to avoid the complexity of most front-end frameworks).
Recently, I was exploring how I could use
van.hydrate
to sprinkle reactivity to html rendered by other backends (e.g. ruby erb templates, python jinja templates, etc.). I currently use alpine.js for some of our apps, and I'm looking to migrate everything to van.js (not just the interactive parts, but also some SPAs on some pages).I have an example below, but I wanted to get thoughts from the community if there were other recommendations for a cleaner implementation.
Let's assume that we have this html:
This is how the js would look like:
Here's the link to codesandbox.
Beta Was this translation helpful? Give feedback.
All reactions