Feature Request: SFC - A Better New Paradigm

[medz]

I've been thinking about this since 2024, when I was unemployed and trying to do it using macros. Until macros were abandoned (because I really dislike build).

I was pleasantly surprised when you released Solid, because you were continuing something I'd been trying to do but never released. You bravely released it.

Getting back to the point, perhaps we can consider something simpler.

<solid>
final props = $props({
  'firstName': String,
  'lastName': Nullable<String>,
});

final fullName = $('${props.firstName} ${props.lastName}');
int age = $state(0);

void onPlus() => age++;

$.mount(() {
  print('The widget mounted');
});
</solid>

<Column>
  <Text>{{ fullName }}</Text> // t1
  <Text>{{ age }}</Text> // t2
  <TextButton
    @tap="onPlus"
    >Plus one age</TextButton>
</Column>

Why do we need to do this?

It's difficult. First, we need to write a Solid parser for Solid. Implementing syntax highlighting within the special tag <solid> is something I've considered for a long time.

For example, int age = $state(0); ultimately needs to be split into independent getters and setters.

Essentially, $props, $state, and $ are macro-like markers that perform syntax transformations within the Solid source code.

Why is this necessary? This is one of the most ideal forms where developers can have complete control over Widgets without changing the Flutter framework. Especially when using built-in Widgets, by tracking the state, only the dependent Widgets are rebuilt. That is, when the user clicks Plus one age to trigger onPlus, only t2 will be rebuilt.

Parent Level

<Example firstName="Seven" lastName="Du" />

When firstName or lastName is updated, the component itself will not be rebuilt. Because it can collect props while only triggering the rebuild of the t1 Widget.

---

Emmm, this is a way I've been conceiving for a year to implement SFC based on Dart syntax. I initially implemented its prototype using only macros. If the macros still exist, there's no need to write CLI commands to transform the code.

[medz]

int age = $state(0);

Compiled code:

import 'package:solidart/solidart.dart';

final __solid_state_age = signal(0);
int get age => __solid_state_age.value;
set age(int value) => __solid_state_age.value = value;

[nank1ro]

Thanks for the brave proposal 🙏

This seems a complete new framework, and not Flutter.
This reminds me of Svelte, example code here.

There are many things that scare me about this proposal, but I'm happy to change my mind 😉

1. The code you write in the source folder is no longer valid Dart code
2. We need a custom analyzer that doesn't consider the Dart code invalid, and a custom LSP that helps developing. What about working with other existing generators? We should leverage the existing packages the most we can.
3. Seems like a JSX syntax, typical on web. But how can we ensure only some widgets accept children, like Column? How do you pass a component to another component? Seeing the output code of your input would help.
4. Does Column, Text etc need to be rewritten from scratch to support this? In case this would be a huge effort (surely not something we can support for a long term) and would surely decrease the user interest.
5. why Nullable<String> when we already have String? in Dart?

[medz]

The code you write in the source folder is no longer valid Dart code

No, the code written within the <solid> tag in the .solid file is valid Dart code, subject to the Dart parser and Dart syntax. This is precisely why I designed it this way—to directly enable the Dart parser for <solid>. It's similar to Svelte, except with some added special rules. These rules are type-safe, and the Dart parser will process them correctly (unless it goes through the Solid compiler, in which case it will have no effect).

We need a custom analyzer that doesn't consider the Dart code invalid, and a custom LSP that helps developing. What about working with other existing generators? We should leverage the existing packages the most we can.

For example, this example.solid file will be compiled and output to the .solid/cache/example.dart file. It contains completely normal Dart code.

I've solved this before by using Dart AST to separate the import, part, class, etc. code from the <solid> tag to the top level of the file.

Alternatively, you can use Vue/Svelte's scope syntax. The file itself only exposes the compiled widget itself. You define the widget's code using <solid scoped>. Without the scoped tag, everything inside is just like in a .dart file.

Seems like a JSX syntax, typical on web. But how can we ensure only some widgets accept children, like Column? How do you pass a component to another component? Seeing the output code of your input would help.

This presents a compatibility challenge. Firstly, it requires component constraints similar to React/Vue/ng, where a single descendant is child with the signature Widget, and multiple descendants require children with the signature <List<Widget>>.

SFC Interface:

interface class SFCWithChild<T extends Widget?> {
  const SFCWithChild({ required T child });
}
interface class SFCWithChildren<T extends List<Widget?>?> {
  const SFCWithChild({ required T children });
}

For Flutter's built-in widgets, we can use generators to specify individual tags. Other widget library authors can implement this interface to let Solid know whether it accepts a group of widgets or a single widget.

Does Column, Text etc need to be rewritten from scratch to support this? In case this would be a huge effort (surely not something we can support for a long term) and would surely decrease the user interest.

No need, because I considered interoperability from the very beginning. Therefore, the final compiled content of Solid SFC is the Flutter Widget.

why Nullable when we already have String? in Dart?

This is for syntax expansion, as mentioned earlier. Within the <solid> tag, there is pure Dart code; only the $ symbol is special code, but it's also normal Dart code that has no effect (designed to avoid modifying the Dart analyzer). It only gets converted to other code by the Solid compiler.

$props accepts a Map of type Map<String, Type>. final p = {'a': String}; is considered normal syntax in Dart. However, {'a': String?} will be marked as erroneous syntax by the Dart analyzer (and is indeed erroneous). I also designed a way to allow default values:

final prosp = $props({
  'a': String, // Required a String type
  'b': Nullable<String>, // A `String?` type prop.
  'c': withDefault<String>('Hello'), // A c prop with `Hello` to default value
});

The signature code of the $props function:

$props(Map<String, Type> props);

---

I can answer many more questions one by one; I've really been researching this for a long time.

Originally, I planned to write a prototype compiler, but I've been quite busy with work for the past two months.

This proposal doesn't need to be adopted immediately, because you need to truly understand the microarchitectural advantages of SFC and the burden on users when writing code.

If necessary, you can try having AI write a simplified version of the prototype verification compiler.

[medz]

Simple 1 a.solid:

<solid scoped>
int count = $state(0);
</solid>

<GestureDetector @tap="() => count++">
  <Text>{{ count }}</Text>
</GestureDetector>

Built widget code:

class A extends SolidWidget {
   A({super.key});

   late final __count_state = signal<int>(0);
   int get count => __count_state.value;
   set count(int value) => __count_state.value = value;

  @override
  Widget build(BuildContext context) {
    return GestureDetector(
      onTap: () => count++,
      child: SolidBuilder(
        builder: () => count.toString(),
      ),
    );
  }
}

Simple 2 b.dart:

<solid scoped>
final props = $props({'name': String});
</solid>

<Text>{{ name }}</Text>

class B extends SolidWidget {
  const B({super.key});

  final String name;

  @override
  Widget build(BuildContext context) => Text(name.toString()); 
}

[medz]

Another point worth mentioning is that if Dart supports the SourceMap proposal, then you can directly locate the .solid source code from the compiled Dart code.

[medz]

This seems a complete new framework, and not Flutter.

@nank1ro Yes, but also no!

SFC syntax is merely a "template syntax" that ultimately generates more controllable Dart and Flutter Widget code.

Saying it's a new framework "not Flutter"

Because it uses entirely new syntax and adds a lot of syntactic sugar to Dart code while still adhering to Dart syntax.

Saying it's not a new framework "is Flutter"

Because its final output is still Flutter Widgets, valid Dart code.

Other

Even other authors can directly write Flutter Widgets using Solid, compile them using the solid build command, and publish them to Pub.

Implied meaning

The reason I ultimately didn't implement it in 2024: After prototyping and validating SFC, I wondered, since we have a new syntax, why be limited by the Flutter framework itself?

So around October 2024, I started thinking about and researching Flutter Engine and Fluter Bindings. I was trying to bypass the Flutter framework itself and develop a completely new framework based on the Flutter underlying engine, using that syntax.

The reasons I didn't implement this were:

1. When I researched Flutter Engine and Bindings, I suddenly realized that this wasn't something I could develop alone.

2. I suddenly received an interview invitation and successfully got an offer.

However, the conversion of SFC to Flutter Widgets is a good fit for Solid at its current stage. Because Solid has a CLI (Generator), Solid is still built on top of Flutter.

[medz]

This reminds me of Svelte

Yes! I have over 10 years of experience writing React and Vue code, and 5 years of experience writing Svelte code (although I primarily work in backend development).

For web frameworks, I've studied the source code of all of them except Angular, and I've used them in actual projects. (I really hate Angular!)

So this SFC comes from them, using what I consider the least boilerplate and most user-friendly parts of each framework.

Even the <solid> parser is a port of the Dart parser, which I learned from Vue's approach of directly embedding a JavaScript parser in <script> tags during prototyping last year.

The DOM part is based on Svelte's approach of directly enabling the HTML parser at the tag position.

---

You might consider this SFC lacking in originality, but its originality lies in:

1. Using SFC (Single File Component) to write Widgets.
2. Drawing on and summarizing decades of pioneering experience.

PS: This is off-topic. Please read and then hide.

[nank1ro]

PS: This is off-topic. Please read and then hide.

Consider that I read all the message before reading the bottom line 😂

[nank1ro]

Another point worth mentioning is that if Dart supports the SourceMap proposal, then you can directly locate the .solid source code from the compiled Dart code.

Do you have a link to the proposal? Feel free to attach it to the first post to give more context

[nank1ro]

No, the code written within the tag in the .solid file is valid Dart code, subject to the Dart parser and Dart syntax. This is precisely why I designed it this way—to directly enable the Dart parser for . It's similar to Svelte, except with some added special rules. These rules are type-safe, and the Dart parser will process them correctly (unless it goes through the Solid compiler, in which case it will have no effect).

Can you clarify this? See image below.

Of course $ functions can be declared, but what about <solid>?
What if the user wants to write multiple widgets in the same file? Impossible right? In Flutter it's very common to have many small widgets that compose a bigger widget in the same file.

[nank1ro]

Simple 1 a.solid:

<solid scoped>
int count = $state(0);
</solid>

<GestureDetector @tap="() => count++">
  <Text>{{ count }}</Text>
</GestureDetector>

Built widget code:

class A extends SolidWidget {
   A({super.key});

   late final __count_state = signal<int>(0);
   int get count => __count_state.value;
   set count(int value) => __count_state.value = value;

  @override
  Widget build(BuildContext context) {
    return GestureDetector(
      onTap: () => count++,
      child: SolidBuilder(
        builder: () => count.toString(),
      ),
    );
  }
}

1. Where the Text widget goes? I don't see it anymore?
2. Why @tap becomes onTap?
3. Why @tap="() => count++" is a string and not a function? Not easy to debug code for the user.
4. What if a Widget takes top, bottom, leading and bottom Widgets as parameters? how do you pass them?

[nank1ro]

But first, and probably the most important question, why do you hate the build method?

This proposal is very far away from writing Flutter code, users that already know Flutter won't like it for this reason.
It requires a lot to learn a new framework, which is not an easy task, unless you already know Svelte/Vue/SolidJS

[medz]

Do you have a link to the proposal? Feel free to attach it to the first post to give more context

https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit?tab=t.0#heading=h.1ce2c87bpj24

PS: What I mean is, in one .dart file, a SourceMap is used to point to another source code mapping.

Where the Text widget goes? I don't see it anymore?

😂I've forgotten the pseudocode I wrote by hand.

Why @tap becomes onTap?

This is a reference to Vue. Considering that not all widgets use the standard onXXX to represent event functions, it could be modified to <A onTap={() => count++} />

Alternatively, it could retain @tap=xxx, which indicates that a function signature type must be passed at the beginning of on.

Why @tap="() => count++" is a string and not a function? Not easy to debug code for the user.

The @ symbol is a special DOM syntax, inspired by Vue. Its content is represented in Dart language. Alternatively, @tap={() => count++} is also acceptable; it simply indicates the start and end of the value passed in onTap. The reason for choosing " is to facilitate later AST parsing. The HTML parser can be used directly; only in LSP, because the prop starts with @, the Dart parser needs to be enabled.

What if a Widget takes top, bottom, leading and bottom Widgets as parameters? how do you pass them?

<AppBar
  bottom={<ButtomNavBar ... />}
  actions={[
    <TextButton @tap="...">...
  ]}
  title={<Text>Title</Text>}
>

// OR
<solid>
final bottom = <ButtomNavBar .../>;
// OR, Traditional Widget class creation method
final bottom = ButtomNavBar(...);

final actions = [
  <TextButton @tap="...">...</TextButton>
  ...
];
</solid>

<AppBar bottom={bottom} actions={actions} title={Text('Title')}>

但首先，也是最重要的问题，你为什么讨厌这种build方法？

First, let me clarify that I don't dislike the build method. If you've seen my reply to the Flutter official tweet about X, you should know that the current Widget syntax is exactly the same as React's ten years ago.

Everything Google open-sources is contradictory; they create the beginning of an era, then fall behind.

If you follow front-end development, you should know that ng practically formed the cornerstone of modern front-end development, but ng has been stagnant for over a decade.

I really like Dart because the dedication of Dart's language engineers makes Dart intuitively aligned with human natural language. I also really like Flutter, but undeniably, Flutter's weakness lies in its lack of exploratory spirit beyond cross-platform compatibility.

Solid rekindled my initial enthusiasm for seeing Vue emerge from ng. Perhaps Solid is now built on Flutter, but if it truly becomes popular and receives sufficient open-source funding, it's the most likely first native framework to achieve modern cross-platform compatibility.

Then Flutter will fall behind the times and repeat the demise of Angular (or the Flutter team will actually make changes).

I spent two years reading every line of Flutter code, and the implementation of the Flutter front-end UI is truly outdated and inefficient. This is why they keep telling users they need to use const and StatelessWidget for better performance.

They are very aggressive and exploratory in low-level rendering, but their presentation layer is outdated and they are unwilling to optimize it deeply.

If React had continued to insist on its presentation layer like Flutter and ignored hooks, we might not see the React framework today.

As we discussed on X timeline, developers in the Dart ecosystem (especially top developers) lack the exploratory and geeky spirit of JavaScript developers. They are conservative and focused on so-called "good paradigms."

[medz]

Aside: Please hide after reading

Q: Why do I see issues but not submit issues or PRs?

A: It's difficult. Large companies' open-source projects are usually reluctant to accept major changes unless they want to. Years ago, I tried to fix a tiny part of the Dart team's ecosystem. It took weeks and a very cumbersome process.

I feel I don't have that much time to waste on that again; I need to work to support my family. I also have many of my own ideas to develop and build.

And I tend to be quite aggressive with technology, so I contribute relatively little to existing libraries. Because my ideas are often quite radical. Something I conceived a long time ago, I even used internally for over a year. Three years later, I saw someone finally build it. But I myself lacked the funds to invest in these ideas.

Actually, I just want to write code; I never think about commercialization or how to make money, because writing code is my hobby. My technical skills aren't great, but I really enjoy learning new things. Therefore, my knowledge is very diverse and disorganized.

---

Conversely, I prefer submitting issues or pull requests to the JS ecosystem (usually there's no need for this; their thinking is often ahead of mine).

Because once I submit to their ecosystem, their reaction is: "Wow! That's cool, let's validate and have users vote!" or "We'll keep it and provide it in the future."

Submitting to large companies like Google is always: "Emmm~ This doesn't fit our philosophy" or "We can't accept this."

It's really annoying.

This is also the main reason why alien-signals are accepted by Vue, and why frameworks like Preact and SolidJS exist!

Imagine what would happen if this happened to Flutter? They wouldn't even validate it; their first reaction upon seeing the code would be: "This change is too big; we can't accept it." They wouldn't even bother to validate it. This causes immense frustration for contributors, and it's the main reason why most open-source developers are unwilling to submit feats for many large companies' open-source products!