(no title)
TonyPeakman | 5 months ago
On syntax: you’re right that +/* aren’t XML/XHTML-friendly. The short, stackable directives were chosen for ergonomics, but I’m considering offering a dg-* variant to improve standards compliance where XML/XHTML interoperability matters.
Appreciate the push here — keeping the buildless path the default while tightening standards compliance is exactly where I want to take dagger.js next.
em-bee|5 months ago
if i may make a suggestion here, you could use the type as part of the name:
so +load becomes lifecycle.load
*value would be control.value
+click would be event.click
@raw would be meta.raw
. because i think only _ . and - are allowed. you want to keep - for complex names: control.some-value and _ doesn't feel right.
maybe you want to choose other names. aurelia uses this approach with different names. i didn't want to influence you to choose aurelias names, so i picked those from the table on https://daggerjs.org/#/directive/introduction
keeping the names in line with the terminology you use makes it easy to remember them and also to look them up. (what is a lifecycle? i can just search for it. the only downside is that lifecycle in particular is long, so if that is used frequently, a shorter name might be preferable. maybe just 'cycle')
oh and while we are talking about about verbosity. i saw one router example that looked a bit verbose. but maybe that's because it tries to show all the options you can set on a route.
a minimalist example would be nice to see there in contrast. (maybe there is one and i just didn't find it)
TonyPeakman|5 months ago
The original react router demo as a comparison: https://codepen.io/pshrmn/pen/YZXZqM?editors=0010
TonyPeakman|5 months ago
You’re right that symbols like +//@ aren’t valid in XML/XHTML, and the original idea was just to keep things as short and stackable as possible. But I see the value in a more standard, semantic form like lifecycle.load, control.value, event.click, meta.raw. It’s clearer, easier to search, and plays nicely with stricter environments.
I’m leaning toward offering both: the current short symbols for quick prototyping, and a more verbose but standard form (potentially with dg- or dot-namespaced attributes) for projects that need stronger compatibility. Your idea of aligning the names with the terminology we already use makes a lot of sense.
And thanks for pointing out the router example — you’re right, the docs only show the “all options” version. I’ll add a minimalist example alongside it so people can see the simple path too.
Appreciate the thoughtful feedback — this gives me a clear direction for making dagger.js easier to use while staying standards-compliant.