Does the VSCode extension really not have any code snippets?

[HeCorr]

I'm surprised there doesn't seem to be snippets for Components like there are for Flutter Widgets (stful & stless).

Because of this I keep having to copy existing Components when creating new ones.

[schultek]

There is a quick action in jaspr_lints to create component boilerplates.

But still good idea, what snippets would you like to see?

[HeCorr]

I guess the same ones from Flutter: stful, stless, initState, etc plus of course the Jaspr-specific ones that Flutter doesn't have.

[schultek]

The extension now comes with snippets like jstful, jstless and more like jhtml and jtext.

[YashMakan]

I did try something related to this so think will put this here if it helps anyone

@schultek do let me know your thoughts on this kind of approach as well,

import 'package:jaspr/jaspr.dart';

typedef Widget = Component;

abstract class StatelessWidget extends StatelessComponent {
  const StatelessWidget({super.key});

  @override
  Iterable<Component> build(BuildContext context) sync* {
    yield render(context);
  }

  Component render(BuildContext context);
}

abstract class StatefulWidget extends StatefulComponent {
  const StatefulWidget({super.key});

  @override
  State<StatefulWidget> createState();
}

abstract class WidgetState<T extends StatefulWidget> extends State<T> {
  @override
  Iterable<Component> build(BuildContext context) sync* {
    yield render(context);
  }

  /// Subclasses should implement this instead of `build`
  Component render(BuildContext context);
}

class Group extends StatelessComponent {
  final List<Component> children;

  Group({required this.children});

  @override
  Iterable<Component> build(BuildContext context) {
    return children;
  }
}

class Div extends StatelessWidget {
  final String? style;
  final String? cls;
  final Component? child;

  const Div({super.key, this.style, this.cls, this.child});

  @override
  Component render(BuildContext context) {
    return DomComponent(
        tag: 'div', classes: '${style ?? ''} ${cls ?? ''}', child: child);
  }
}

// .... more widgets/components 

---

Then with this utility file, I can use it in more like a flutter way which makes it feel little bit more like home. I can then use the same stless and stful snippets that the flutter extension provides.

import 'package:shipfast_clone/shared/utils.dart';

class LeaderboardButton extends StatelessWidget {
  const LeaderboardButton({super.key});

  @override
  Widget render(BuildContext context) {
    return Div(
        style: '...', // use tailwind css
        child: Group(
            children: [
              Text('Press'),
              Span(
                  style: '...',
                  child: Text('L')
              ),
              Text('to see the Leaderboards'),
            ]
        )
    );
  }
}

[schultek]

There is a reason I made Components the way they are. I don't get why you would rename and reimplement this, please don't do this. Its just unnecessary overhead. Especially the Group, Div etc. already exists in the framework.

[YashMakan]

Firstly, I want to say really love your work on Jaspr — it's a super interesting approach and I love the direction it's taking. I've been exploring it and trying to use it in a way that aligns with my existing habits and background (especially as someone coming from Flutter and almost no web experience).

I ended up creating a small utility layer around StatelessComponent and StatefulComponent to make it feel more intuitive for my workflow. Just wanted to share my reasoning behind that and would love to hear your thoughts on whether this approach makes sense, or if I’m missing any deeper patterns you had in mind.

Here are a few reasons behind the decisions:

1. Coming from Flutter, I’m used to components being PascalCase. Using lowercase tags like div and span alongside MyCustomComponent felt inconsistent to me. Naming everything as PascalCase (like Div, Span) helped maintain visual structure in the widget tree and my sanity.

2. Tailwind + Classes: I’m using Tailwind CSS in my project, but passing styles via the classes prop felt a bit messy(again coming from flutter styles). So instead of:

div(classes: 'bg-blue-500')

I preferred:

Div(styles: 'bg-blue-500')

It’s syntactically cleaner, I think

3. No empty arrays by default: Calling Div([]) when there are no children feels slightly awkward to me. It adds unnecessary visual noise, and having just Div() feels more natural — especially when the component is being used for spacing, layout, or as a container.

4. Component nesting with brackets: As soon as files grow beyond ~100 lines, all the nested square brackets make it harder to follow the hierarchy. Wrapping elements like Div, Section, Header, etc., makes things more Flutter-esque, and more readable at a glance (at least to me).

5. Child over children: I prefer the child approach by default, like Flutter, and explicitly using Group or Fragment when I want multiple children. I find it helps me mentally track layout trees better and I dont have to use children: [text('Hello World!')] even if only one component needs to be present, instead I prefer it to be child: text('Hello World!'), if I want list of components, I like to specify that myself with something like Group as I implemented in the utility class which basically does the same thing underneath but yea...

6. StatelessWidget vs StatelessComponent: This is mostly a tooling thing — I’m on Android Studio and couldn’t find a Jaspr extension, so writing out StatelessComponent manually was repetitive. Wrapping it into a StatelessWidget makes the boilerplate bearable once the utility is in place.

7. Separation of concerns: Creating this wrapper layer helps abstract DomComponent details so that my app code can focus just on layout and logic, not on tag or attribute boilerplate. That separation feels like a win for maintainability.

That said, I genuinely want to learn — is this kind of abstraction something you think goes against the Jaspr design philosophy? I totally understand if it's not aligned, but curious if there’s a better or more idiomatic way to achieve similar cleanliness.

Thanks for reading and really appreciate all the work you’ve done with Jaspr 😊

P.S. I’ve built a clone of shipfa.st using Jaspr, incorporating the patterns I mentioned above. Would love to hear your thoughts regarding this as well.

https://yashmakan.github.io/shipfast-clone
https://github.com/YashMakan/shipfast-clone

[schultek]

Most of these points are just small syntax changes. I don't mind since its your personal preference and you can do what you like for your own projects. But I'd prefer if you not advertise this to others, since that then makes things inconsistent and can lead to confusion at best and fragmentation at worst.

I personally don't think the changes you made are particularly "better" than the current syntax. There is always a tradeoff. For example having an optional children: [] instead of required [] is denser for empty children, but much more verbose for everything else, thats why I decided against it:

yield div([
  p([text('Hello')]),
  div([]) //spacer
  span([text('World')]),
]);

is much nicer imo than

yield div(children: [
  p(children: [text('Hello')]),
  div() //spacer
  span(children: [text('World')]),
]);

And there are similar tradeoffs for the other points you mentioned.

---

That said I really appreciate detailed feedback like this. It helps me get a sense of what the devex is like for others and where to look into next. I'm constantly re-evaluating things like this, but I also need to keep in mind things like 'how big of a breaking change would something be'.