32 Matching Annotations
  1. Oct 2021
    1. If foo is a function, foo is called with the current node as its argument. Else if org-roam-node-foo is a function, foo is called with the current node as its argument. The org-roam-node- prefix defines many of Org-roam’s node accessors such as org-roam-node-title and org-roam-node-level. Else look up org-roam-capture--info for foo. This is an internal variable that is set before the capture process begins. If none of the above applies, read a string using completing-read. Org-roam also provides the ${foo=default_val} syntax, where if a default value is provided, will be the initial value for the foo key during minibuffer completion.

      Click here to get a handle on the behavior of the expansions in multiple context.

    2. Org-roam provides the ${foo} syntax for substituting variables with known strings. ${foo}’s substitution is performed as follows:

      Org-roam Template has expansions with similar syntax to yasnippet!

    3. Org-roam’s templates are specified by org-roam-capture-templates
    4. Org-roam capture templates are incompatible with org-capture templates.
  2. May 2021
  3. Mar 2021
    1. My preference here is biased by the fact that I spend everyday at work building web components, so Svelte's approach feels very familiar to slots in web components.

      first sighting: That <template>/<slot> is part of HTML standard and the reason Svelte uses similar/same syntax is probably because it was trying to make it match / based on that syntax (as they did with other areas of the syntax, some of it even JS/JSX-like, but more leaning towards HTML-like) so that it's familiar and consistent across platforms.

    2. I was pleasantly surprised by Svelte's templating; in the past I've found templating languages overwhelming and inflexible, but Svelte offers just the right amount of templating whilst enabling you to use JavaScript too.
  4. Nov 2020
    1. Partials
    2. We all know that real business logic does not belong in the presentation layer, but what about simple presentation-oriented things like coloring alternate rows in table or marking the selected option in a <select> dropdown? It seems equally wrong to ask the controller/business logic code to compute these down to simple booleans in order to reduce the logic in the presentation template. This route just lead to polluting the business layer code with presentation-oriented logic.
    3. Templates with logic versus "logic-less" templates is a hotly debated point among template language designer and users. Dust straddles the divide by adopting a "less logic" stance.
    1. The success of JSX has proved that the second curly is unnecessary. Moreover, a lot of people — particularly those who have been exposed to React — have a visceral negative reaction to double curlies, many of them assuming that it brings with it all the limitations of crusty old languages like Mustache and Handlebars, where you can't use arbitrary JavaScript in expressions.
  5. Oct 2020
    1. Then at some moment I just stumbled upon limitations and inexpressiveness of templates and started to use JSX everywhere — and because JSX was not a typical thing for Vue I switched to React over time. I don’t want to make a step back.
    1. I think logic-less templates are overrated. We already have logic in components with {#if} so I don't see what the concern is about logic in templates.

    2. Arguably, it leans into JSX land—including logic in the templates.
    3. I could imagine people putting a more complex expression in an @const than we typically find in svelte expressions today, which might create more demand for those blocks to have TypeScript support, which I don't think they have now.
    4. Also a vote against, for the simple reason that logicless templates would be the ultimate goal for me.
    5. one of the reasons people sometimes balk at mustache-like syntax is just that: logic in the templates.
    1. IMO svelte does have a responsibility to teach/demo the basics of "functional javascript" probably as a docs/tutorial/demos chapter on "the power of javascript expressions"
    1. Writing a logic-less template requires a bloated view model with comprehensive getters for the raw data. As a result, a messy and difficult-to-maintain view model usually accompanies logic-less templates.
    2. Full-of-logic, logic-less, and less-logic solutions
    3. that does not mean that I am advocating the other extreme–i.e., a templating language that allows a lot of logic. I find such templating languages, especially those that allow the host programming languages to be used inside the template, to be hard to read, hard to maintain, and simply a bad choice.
    1. Mustache is described as a "logic-less" system because it lacks any explicit control flow statements, like if and else conditionals or for loops
    2. Here, when x is a Boolean value then the section tag acts like an if conditional, but when x is an array then it acts like a foreach loop.
  6. Aug 2020
  7. Feb 2020
  8. Feb 2018
  9. Oct 2016
  10. Jan 2016
    1. but the lack of constraints

      and hilarity ensued...MySpace is/was/never has been less templated than Wordpress. Just not as well templated as Wordpress or as peopled by good developers who add more choice via plug-ins and the WP API. But make no mistake: plug-ins are templates.

    2. A hand-built site is much less templated, as one is free to fully create their digital self in any way possible.

      This is partly true, but....every space is a templated space. Coding creates the space. Text boxes and the metaphor of page and post are templated. Just minimally so. Templates are not the boogey man. A haiku is a template, a sonnet is a template, but is anyone reasonably arguing that Basho and Shakespeare would have been better off not using them. We use templates to create buildings. We call them "forms" and use rebar and concrete to send them to the sky.