Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider JSX-like as React Native #15922

Closed
JonathanSum opened this issue Mar 25, 2018 · 203 comments
Closed

Consider JSX-like as React Native #15922

JonathanSum opened this issue Mar 25, 2018 · 203 comments

Comments

@JonathanSum
Copy link

@JonathanSum JonathanSum commented Mar 25, 2018

For code that builds a UI has to be readable. I understand that Dart is kind of like a simple version of Java, but it is not really a programming language for building a UI. For example, it doesn't have a closing tag. As a result, It is very hard to build a picture in mind with this unreadable code.

Moreover, Flutter was inspired by React. How can Flutter doesn't have JSX but has this kind of unreadable code? I am very scared that Flutter is going to die very soon as the early days of AnglurJs.

I understand people who work in Google are smart, but we also have some people who are not really smart choose React instead of Dart, and this is one of the reasons why Dart was dead in the past.

@JonathanSum JonathanSum changed the title Come on, Let's face this. This flutter framework really need JSX-like syntax Come on, Let's face this. This flutter framework really needs JSX-like syntax Mar 25, 2018
@cbazza
Copy link

@cbazza cbazza commented Mar 25, 2018

This has been asked for a long time:
#11609
Functional prototype developed:
https://spark-heroku-dsx.herokuapp.com/index.html
That shows the alternative and some benefits...


The current issue with DSX is about proper integration with Flutter tools as to provide a great developer experience with debugger, auto-complete, etc. working on .dsx files.

Telling users that they can use DSX but can't use debugger or enjoy auto-complete is a non starter for me. If anybody wants to help, what I need is to figure out a way to add full preprocessing support (with source map) to Dart Tools and VS Code Dart plug in. Once the tools support that DSX or any other transpiling language (any language that is a superset of Dart but compiles everything down to Dart) would just work.

If you can and would like to help, let me know.

@JonathanSum JonathanSum changed the title Come on, Let's face this. This flutter framework really needs JSX-like syntax Come on, Let's face this. This flutter framework really needs JSX-like syntax as what React-Native has. Mar 26, 2018
@escamoteur
Copy link
Contributor

@escamoteur escamoteur commented Mar 26, 2018

I cannot agree. Especially using a IDE like Dart Code you get virtual closing tags which makes readin way easier. With Dart2 where you can omit new it will even get better.

Also I find it discourages you to build too big Widget trees without deconstruct it into smaller easier to maintain widget classes.

@JonathanSum
Copy link
Author

@JonathanSum JonathanSum commented Mar 26, 2018

I use Android Studio. I don't even see a virtual closing tag. Even though we have a virtual closing tag, it is more complicated than HTML that everyone hates. Dart is just a programming language. People in Google don't understand the importance of simplification.

@JonathanSum
Copy link
Author

@JonathanSum JonathanSum commented Mar 26, 2018

close

@carl2013
Copy link

@carl2013 carl2013 commented Mar 26, 2018

I don't think I would like a JSX-like syntax either but yeah, I use IntelliJ and something needs to be done with the tooling so that the UI code is easier to understand.

@cbazza
Copy link

@cbazza cbazza commented Mar 26, 2018

Also I find it discourages you to build too big Widget trees without deconstruct it into smaller easier to maintain widget classes.

I don't see how this is any different than with JSX... as the tree gets larger you can break into smaller sub-trees with both.

I don't think I would like a JSX-like syntax either but yeah, I use IntelliJ and something needs to be done with the tooling so that the UI code is easier to understand.

and it should be easy to read on all platforms and not only Intellij; I mean it should be easy to read on Bitbucket when reviewing code; and it should also be valid when using any editor; I mean with these 'comment annotations' what happens if someone using 'vi' types a different comment in there?

@zoechi
Copy link
Contributor

@zoechi zoechi commented Mar 26, 2018

This is a dup of the locked down #11609
@sethladd ?

@sethladd
Copy link
Contributor

@sethladd sethladd commented Mar 26, 2018

Apologies, you should be seeing the "virtual closing tags" in IntelliJ and Android Studio.

cc @devoncarew to verify which version turned that on, or if the user needs to opt-in ?

We thank you for your comments re: JSX-like syntax. We believe there is opportunity across the language, our tools, and plugins to make editing UI code easier.

This does dupe #11609 but I'd like for @devoncarew or @mit-mit to add a note about how to turn on "virtual closing tags", if possible.

Thanks!

@devoncarew
Copy link
Member

@devoncarew devoncarew commented Mar 26, 2018

@JonathanSum, the closing labels aren't available in Android Studio 3.0 unfortunately. You'll need at least IntelliJ 2017.3 or Android Studio 3.1. Android Studio 3.1 is currently in the release candidate stage, and we plan to release a flutter plugin with support for it tomorrow.

Irrespective of the conversation around a JSX like syntax, we do want to work towards making it easier to write UI code in Dart, in both IntelliJ / Android Studio and in VS Code. That's initially the closing label work, but also the recent Flutter Outline view. That shows the structure of your build() method in an outline view, and allows you to navigate the widgets and more easily see their parent / child relationships. That's currently available in IntelliJ - we do expect to be able to bring it to VS Code as well.

@NathanaelA
Copy link

@NathanaelA NathanaelA commented Mar 26, 2018

@zoechi - This might be a dup; but the other thread got heated, and locked. So their is no way to contribute to that conversation. I don't think you should close this thread as a dup just because you don't like people asking for a feature. This should probably be the new thread for responses for new people coming and requesting JSX support (or similar functionality).


@sethladd - Please do not lock this thread; I do think having community discuss pro's and con's on alternative layout methods is useful. I would have participated in #11609 had it not been locked.


I come from a NativeScript background. I have to say this is one area where I do feel NativeScript is considerably easier to use than Flutter. I can get a fairly complex screens working in less than 5 minutes and easily iterate the design quickly. Then add the code that runs the screen.

In NativeScript we actually have the following files:

  • screen.js / screen.ts (.ts is transpiled into .js if you prefer typescript). This is the main logic for the screen that you are displaying.
  • screen.css (or screen.android.css and/or screen.ios.css) which is a much more limited version of CSS but supports things like height, width, color, background, etc. Most the time a single css file is only needed, but occasionally if you are doing something weird you might separate your css for android and ios. It has full support for Classes, Elements, and id's So I can do TextArea.Login #Password and it actually will limit itself to just that specfic element chain.
  • screen.xml (Again or screen.android.xml and/or screen.ios.xml) - This is the screen layout. You CAN code the layout in JS if you want (basically like flutter); but the XML is so so much easier. Example:
<Page onLoad="loadme">
    <ActionBar title="Blah"><NavigationButton click="back" title="Back"/></ActionBar>
    <StackLayout>
      <Label text="Hi" id="Hi" style="color: red"/>
     <Label text="{{name}}" class="name"></Label>
     <Button text="Click Me" tap="clicker"/>
    </StackLayout></Page>

The interesting thing is that ActionBar is a specific page only component (i.e. it is specific to only Page); so basically what happens is the XML parser See's page; creates a new Page Element; then creates a ActionBar component which it then runs a builderChild function on the Page component; the page component overrides the default builderChild and looks to see if the child is a ActionBar; if it is; then it internally assigns it to the proper variable; otherwise the rest is passed through parent/super which then assigns it to the "child" or "children" components automatically. The build system is incredibly versatile in that each component can use either the parent's builderchild function or override it to do extra items like support <Label>Hi</Label> and assign that to the Text value automatically. This makes layout incredibly easy to get up and running without any code.

Because most editors have good XML editing capability it is automatically colorized and with the proper xsd definition intellij (& vscode) does automatic checking and limited context support.

Now technically everything is actually a JavaScript component; so you can do all this manually (like what Flutter does); but I find the easy of laying out a screen is trivial in NativeScript. And you don't need the JS or CSS when you first start; then you can add the CSS (typically you don't hard code in the layout the css based properties; but you can if you want).

The nice thing about this; is it allows Web developers to jump right in with very little (if any) retraining. In fact; because of its flexible renderer and being JS based -- NativeScript actually support Angular and Vue -- so that you can actually share close to 95% of the code base between web, and your mobile app if you use Angular or Vue. Since it uses Native OS components like react native (not a webview like cordova); it really is a decent cross-platform system (that is imho better than React Native) . However, I can see where there are some strengths that Flutter has that makes it a good complimentary tool for some mobile development as their are some apps that NativeScript is worse at and some it is still the much better for and based on the responses to my issues from Ian; will stay the considerably better tool for in those areas.

@cbazza
Copy link

@cbazza cbazza commented Mar 26, 2018

Better to open that locked thread and copy these comments there so we have a history of full discussions.

@zoechi
Copy link
Contributor

@zoechi zoechi commented Mar 27, 2018

@JonathanSum it's not about whether anyone wants or doesn't wants the feature,
it's whether this is the place to have a heated discussion about it. I guess reddit or similar are better places.

@NathanaelA
Copy link

@NathanaelA NathanaelA commented Mar 27, 2018

@cbazza - I don't disagree; but you have to be very careful in the future to not insinuate things about people. That just inflames the discussion, no matter how idiotic you believe they are being.

@zoechi - Actually I believe any discussion about a new feature should be here. History should be maintained so that when John Doe comes a month from now and searches about XYZ feature he can 👍 an existing feature and/or contribute to it.

@cbazza
Copy link

@cbazza cbazza commented Mar 27, 2018

I don't think that thread is really locked for this long because of my comments. If what I said was so bad how come I can comment on everything else, like for example this thread?

The thread is locked because the Flutter team has no interest in doing this and just want people to stop talking about it.

@sethladd
Copy link
Contributor

@sethladd sethladd commented Mar 27, 2018

Let's please keep the discussion in this issue focused on use cases and examples for a JSX-like feature.

@escamoteur
Copy link
Contributor

@escamoteur escamoteur commented Mar 27, 2018

Actually if NativeScript is that good, why bother with Flutter at all instead of trying to make Flutter NativeScript like.
I'm coming from an XML based Platform (Xamarin Forms) and thought in the beginning it might be more difficult to design in code but that's not the case.
In the contrary it makes is very easy to break down your design in separate classes which are easy to maintain.

@cbazza
Copy link

@cbazza cbazza commented Mar 27, 2018

JSX is designing in code !!!

@sethladd

Let's please keep the discussion in this issue focused on use cases and examples for a JSX-like feature.

OK, Let's talk about my DSX design which can be viewed here:
https://spark-heroku-dsx.herokuapp.com/index.html

It provides a direct mapping to the current way widgets are built and yet provides a JSX like flavour that is very lightweight and familiar to React developers. Is there anything missing in this design? Can this design generate all possible widgets in the wild?

@mrmcq2u
Copy link

@mrmcq2u mrmcq2u commented Mar 27, 2018

Rule of thumb, if you feel one exclamation mark isnt enough you should probably step away from the keyboard and take a break.

@SirComputer1
Copy link

@SirComputer1 SirComputer1 commented Mar 27, 2018

I'm a newcomer to Flutter, having only some experience with Android and Java, and I must say I find what Flutter offers far better than what is being proposed here. I tend to find that XML is ugly and unwieldy. It's so much more beautiful to have a singular closing character, rather than a sea of that makes my code 5x longer, a hatred of mine when editing Android XML, and just virtual closing tags which the vast majority of IDEs which people use support. This is incredibly useful when designing longer structures. The neat nesting XML provides just doesn't outweigh the rest of the disadvantages, in my opinion, especially when 'child:/children:' do almost as good of a job. Dart is incredibly clean, and it is a reason I like it so much. I would be incredibly disappointed if this was to be ruined.

I know that React does it like this, but last time I checked, this place says Flutter. Just because React does it doesn't mean we have to - you're not the only ones jumping ship to here! I very much agree with all the points @escamoteur made. I'm not seeing the point in adding yet another language that people need to handle when using Flutter. We're already using Dart to program most of it, we don't need a load of other things to master! Consistency and simplicity must be valued.

@lukaspili
Copy link
Contributor

@lukaspili lukaspili commented Mar 27, 2018

Some remarks from your DSX vs generated Dart snippets:

  1. Subjective: I don't see any great readability gains. Verbosity is similar - if not a tad longer. Dart IDE plugin provides auto closing tags, which mirrors declarative markup closing tags. If JSX is design in code, then I don't see how widgets in Dart is not.

  2. Multiple properties in <vars>

@<vars>
var textStyle = {
    "textDirection": "TextDirection.ltr",
    "textAlign": "TextAlign.center",
    "overflow": "TextOverflow.ellipsis",
    "style": "new TextStyle(fontWeight: FontWeight.bold)"
};
</vars>@

Being able to define global styles mixing several properties is a nice idea.
However when I'm looking back at my modest flutter experience, I don't see where I would use these.

For Text it seems most of what I need to reuse is defined in TextStyle, rather than a mix of several properties. Maybe you can find another example than Text where that's not the case.

Looking at TextStyle, I find the current immutable + copy() to be great for reusing and composing in Dart:

class Style {
  static const TextStyle avenirNextMedium =
      const TextStyle(
         fontFamily: 'Avenir Next', 
         fontWeight: FontWeight.w500,
      );

  static TextStyle title =
      avenirNextMedium.copyWith(
        color: ColorKit.blue, 
        fontSize: 45.0,
      );
}

new Text(
  'Hello',
  style: Style.title,
),

new Text(
  'Hello2',
  style: Style.title.copyWith(
    color: ColorKit.red,
  ),
),

For reusable Container sharing a same style, I think that creating a custom stateless widget works better than an external defined <vars>. Most of the time, I want also a padding, an ink, a gesture listener or a shadow.

For any of those cases, I would need to compose Container with another widget: Material, Padding, Center etc. So if I have to create a custom reusable "container" widget anyway, I don't see much gain to have an external <vars> style that would just define the properties of a single widget in my reusable widgets hierarchy.

I don't see Flutter's "everything is a widget" work well with "multiple properties" styles.

  1. Not highlighted in your current DSX examples: How would you code an interface with dynamic widgets? Meaning: how to show or not show some widgets depending on a condition.

When doing design in Dart it's easy and convenient to add or not a particular widget into children.
It's also very convenient to dynamically wrap a widget with another. It makes the build() function fluent and easy to understand.

    var children = <Widget>[];
    if(a) {
      children.add(wa);
    }
    
    var wb = Text();
    if(b) {
      wb = Padding(child: wb);
    }
    
    children.add(wb);
@cbazza
Copy link

@cbazza cbazza commented Mar 27, 2018

@SirComputer1 the DSX proposal is an addition, the current way doesn't change so if you don't like it, don't use it, continue as you are today.

The <var> thing was only done for the demo because I didn't want to parse full Dart. The final solution would not include <var> but would use any dart variable. Also the '@' was only done for the demo to make parsing easy. Final solution would not include it.

Don't forget that anything else on the file is your normal Dart code, so you can use that for everything else.

    var children = <Widget>[];
    if(a) {
      children.add(wa);
    }
    
    // You can mix and match both
    var wb = <Text/>;
    if(b) {
      wb = Padding(child: wb);
    }

    // or
    var wb = Text();
    if(b) {
      wb = <Padding> {wb} </Padding>;
    }
    
    children.add(wb);

    children.add(
      <Center>
          {sayHello == true ?
             <Text ['Hello, world!']/>
          :
             <Text ['Good bye']/>
          }
      </Center>
    );

Let's stop comparing DSX with the current way, one is not competing with the other. Some people will prefer JSX and this thread is for them. What I want to know is how can I improve DSX to handle things that it won't work for.

@NathanaelA
Copy link

@NathanaelA NathanaelA commented Mar 27, 2018

@escamoteur - I don't tend to use a hammer as a screw driver. I evaluate the different technologies and use the proper one for the proper use case. That doesn't mean their isn't things can could be changed for the better in each of the platforms. 😀

For example; third party plugins integration. NativeScript is truly king over every single other cross platform. Nothing else even remotely comes close to NativeScript; and third party integration. I have a client asking about using https://github.com/vipulasri/Timeline-View . Flutter virtually impossible; NativeScript give me a couple hours and it will work just like any other NS control probably even with fully working data binding. On the flip side flutter has some serious strengths where NS flags...

Use the proper tool for the job. 😀


I do tend to like the XML based screen layout; but I do understand why people don't. Adding the ability for XML based building does NOT mean eliminating the existing method; it is just complementary; choice. For those of you who didn't bother reading, I can do the same chain of calls in NS that we do in flutter; but using xml is a lot less typings and easier to me to read. Everybody has their preferences...

I have actually thought about adding a XML based renderer to Flutter as a POC; but I haven't had the spare time. I just wanted to contribute to the conversation and say I would like to see this move forward; but I actually do not expect the core team to work on it. I think NS XML format could be done as community projects where those of us who care (i.e. probably me 😀) would be willing to do the work on them. However, my biggest concern @sethladd -- is if I spend a lot of time on a patch; will it be rejected because someone on the core team absolutely opposes this ability. That is what I would like to nail down first before I spend any time on this...

@cbazza
Copy link

@cbazza cbazza commented Mar 27, 2018

@NathanaelA Fantastic perspective !!!!!!! and look I used lots of exclaimation marks ;-) You literally nailed it on the head.

Yes, I can do DSX but I need a way to integrate it in the current Flutter build system so I need commitment from the current Flutter team before I move forward. IDE integration is virtually trivial on VS Code but not so much with Intellij (unless Google has access to Intellij JSX support).

@JonathanSum
Copy link
Author

@JonathanSum JonathanSum commented Mar 28, 2018

@zoech, No! I think this is an issue. I remember developing an android app with native Java and XML. We still use XML for UI language part. I think using Dart for logic and UI is kind of odd, and this problem is kind of obvious. furthermore, I just hope Google is going to add the UI idea of React into the flutter. The UI part of React is very powerful and concise.

@zoechi
Copy link
Contributor

@zoechi zoechi commented Mar 28, 2018

@JonathanSum I have seen many comments about this.
For me it still looks like something people want because they are reluctant to change their habits, not because it's a benefit for the platform.

@yuu2lee4
Copy link

@yuu2lee4 yuu2lee4 commented Mar 28, 2018

Some people like jsx, Some people dont. Why dont support the two ways to implement UI. You can write jsx-like syntax,and it will finally be comeplied to flutter native syntax,why not support?

@zoechi
Copy link
Contributor

@zoechi zoechi commented Mar 28, 2018

@cbazza
Copy link

@cbazza cbazza commented Mar 28, 2018

@zoechi

For me it still looks like something people want because they are reluctant to change their habits

This is a fair observation but wouldn't it be better for Flutter to be an enabler and remove as much friction as possible for people (outside Google) to adopt Flutter? This gate-keeping behavior is not winning hearts and minds of developers.

@yuu2lee4

Some people like jsx, Some people dont. Why dont support the two ways to implement UI. You can write jsx-like syntax,and it will finally be comeplied to flutter native syntax,why not support?

Excellent question. Given that I am doing all work on DSX, which is just like JSX, and @Hixie personally sent me email excited about the progress, I don't see why not support it, I don't see why not extend a hand and say 'What can I do to help you? What is blocking you to do this?'

@JonathanSum
Copy link
Author

@JonathanSum JonathanSum commented Mar 23, 2019

Hey i-Schuetz.
there is a reply section.

image

This is what I have been saying in this long post. JSX fixed the "spaghetti problem of HTML and XML" (unreadable and complicated UI code). In my personal opinion after using flutter, it is more complicated than JSX or worst.

In these years, I have been seeing people said Flutter cannot capture some of the advantages from React, for example, the true idea of everything is components.

@i-schuetz
Copy link
Contributor

@i-schuetz i-schuetz commented Mar 23, 2019

Not sure I follow. In the text you highlighted, the user is saying that he found JSX easier to learn because he was familiar with HTML and it has a similar syntax. I don't see how this justifies the existence of JSX and even less an imitation for Flutter in any way.

I didn't add the replies to the screenshots simply because the images would take too much space. They seemed rather supportive of what I posted, so also redundant. I posted links.

@filleduchaos
Copy link
Contributor

@filleduchaos filleduchaos commented Mar 24, 2019

@JonathanSum is Flutter more complicated than JSX, or is Flutter different from React and that's causing friction from you? It's more verbose in some cases, yes, and quite arguably less readable without virtual closing tags in an IDE, but I'm not quite sure how using constructors is more complicated than writing an XML-like DSL and I'm still not quite sure why so many people seem to think said XML-like DSL would be a silver bullet that would make using Flutter easier to understand. Especially considering that Flutter has no prior history with the problems that React/JSX was created to solve - React makes DOM manipulation easier and cleaner, and that's nice, but what exactly does that have to do with Flutter again?

In these years, I have been seeing people said Flutter cannot capture some of the advantages from React, for example, the true idea of everything is components.

Without touching the notion that React has some "true" idea of everything being components that Flutter does not, there are also some advantages of Flutter/Dart's design that React/JS cannot capture. And you can say the same (and vice versa) for most decent UI SDKs/frameworks/libraries. Incredibly, different projects are in fact different; perhaps people coming to one project might be better served if they don't start out expecting it to be [insert project they've used in the past]. 🙂

@rrousselGit
Copy link
Contributor

@rrousselGit rrousselGit commented Mar 24, 2019

There are some interesting ideas out there https://github.com/munificent/ui-as-code

@filleduchaos
Copy link
Contributor

@filleduchaos filleduchaos commented Mar 24, 2019

It would most likely be quite the breaking change, but the parameter freedom proposal got me thinking how much more concise build methods could be if Dart had e.g. Crystal's method arguments spec.

Of course, Crystal's compiler would come last in a race against a slug and a tortoise, so there's that 😅

@yisar
Copy link

@yisar yisar commented Mar 24, 2019

I now agree not to add JSX and not to put extra pressure on flutter.

But as far as dart is concerned, it's far less elegant than JS or TS. I feel helpless

@woodstream
Copy link

@woodstream woodstream commented Mar 29, 2019

For instance, the development route of Microsoft UI technology is WinForm to WPF,and now in Flutter,abandon WPF and use WinForm instead。In response to developer‘s complaints, the Flutter team worked hard to implement the WinForm‘s visual window and property editor。

@elMuso
Copy link

@elMuso elMuso commented Apr 19, 2019

As a newcomer in flutter i must say thet this should be in the roadmap. If not jsx, a more human readable way of laying down widgets.

I can see a react class render function and and image of the rendered class and associate at the moment.

I can see a dart file and the rendered content and i will take 5-6 minutes to figure out how it works ...

I can make a semi-complex react class in 5 minutes in an plain text editor , because it's intuitive

I can't do that in flutter. Without autocompletion i'm done as a developer. I don't like to be dependent in a extension for developing something -.-

However. It's gonna be interesting how dart developers deal with this "problem" . In dart 2 they made it more readable . I don't know how they are gonna improve the readability in dart 3 -4 -5 . but i think a refactoring of the components build function is gonna be needed sooner or later.

EDIT:
Nevermind, just tried React Native again , and i hated jsx , the props system , the fact that everything was dynamic was really scary concept again , i guess it's just a personal opinion then. Leave flutter as it is....

@chhornponleu
Copy link

@chhornponleu chhornponleu commented Apr 29, 2019

They requested DSX, not only because they love JSX. They want Flutter.

@aerozavr
Copy link

@aerozavr aerozavr commented May 13, 2019

UI declaration should be visually separated in the code for better code readability and support. Especially in large teams with lots of juniors/middles. Coming from Adobe Flex I can say that reading Flutter's UI declarations reduce productivity badly.
If not DSX(which would be awesome IMO) but something should be done with current situation at least on IDE level.
All of the former UI development frameworks had this feature and we should have it too.

@cbazza
Copy link

@cbazza cbazza commented May 13, 2019

UI declaration should be visually separated in the code for better code readability and support.

and for better integration with other tools like 'gui builders' for example.

@leossmith
Copy link

@leossmith leossmith commented May 13, 2019

Coming from Adobe Flex I can say that reading Flutter's UI declarations reduce productivity badly.

Imagine a UI declaration like MXML with Flutters power! I can only dream!

@Hixie
Copy link
Member

@Hixie Hixie commented May 13, 2019

Now that we have codegen support, the best way to get something like this into the product is to create a package that enables it and show that it is hugely popular.

@a14n
Copy link
Contributor

@a14n a14n commented May 13, 2019

@Hixie is there any pointer to doc for codegen?

@cbazza
Copy link

@cbazza cbazza commented May 13, 2019

Now that we have codegen support, the best way to get something like this into the product is to create a package that enables it and show that it is hugely popular.

It looks to me like codegen is just for .dart -> .dart, the input file must be valid .dart file. That is not very useful for .dsx files since it is a superset of dart. I still need support for cross-compiling into .dart with source maps like features for debugging, etc.

@i-schuetz
Copy link
Contributor

@i-schuetz i-schuetz commented Jun 4, 2019

Please give SwiftUI, which was released yesterday, a look. This seems to be what Flutter should be aiming to, instead of React-like markup.

@filleduchaos
Copy link
Contributor

@filleduchaos filleduchaos commented Jun 4, 2019

Swift's implicit member expressions alone would be so amazing

@rrousselGit
Copy link
Contributor

@rrousselGit rrousselGit commented Jun 4, 2019

I'm mixed about SwiftUI syntax. It's lite for sure, but some aspects look magical.

But we can technically have something relatively similar already:

Column(mainAxisSize: MainAxisSize.min)([
  if (foo) Text('foo'),
  Text('bar'),
]);

That's valid dart code, where Column is still a class.

Here's a stateless widget showcasing it:

class Foo extends StatelessWidget {
  const Foo({Key key}) : this._(key: key);
  const Foo._({Key key, this.children}) : super(key: key);

  final List<Widget> children;

  @override
  Widget build(BuildContext context) {
    return Column(children: children);
  }

  Foo call(List<Widget> children) {
    return Foo._(key: key, children: children);
  }
}

It's boilerplat-ish, but a code-generator can help – especially with the upcoming extension members.


The only issue about this approach is that we're both losing const constructors (since it uses a function to specify children) and instantiate the widget class twice.

If that syntax is desired, ideally instead of a call method, it should be implemented using constructor currying.

@filleduchaos
Copy link
Contributor

@filleduchaos filleduchaos commented Jun 4, 2019

@rrousselGit I'm curious about what aspects of SwiftUI look magical to you - it seems like pretty straightforward extension of Swift syntax to me.

@rrousselGit
Copy link
Contributor

@rrousselGit rrousselGit commented Jun 4, 2019

On their code example from here:

  • Content is mutable? Does that mean they have a built-in Mobx / Vue store?
  • What's that @State?
  • Why is body a variable? Is that a getter? If so, when is the getter called again?
  • is body part of an interface, or many similar variables inside Content?
  • What does that item in exactly do? Why is the right operand of in not something iterable, but the "result" instead?
  • Why is the Image aligned left to the title/subtitle when there's no HStack?

I can't remember for certain, but I'm pretty sure I didn't have such questions when picking up Flutter.

@filleduchaos
Copy link
Contributor

@filleduchaos filleduchaos commented Jun 4, 2019

@rrousselGit That might be because of your background, not because Flutter syntax or semantics is inherently obvious (I've met plenty of people who were quite stumped by it). And the points you've raised seem to be a weird junction of overanalysing a 14-line code snippet for faults while not actually knowing the language it's written in.

  • It's not really mutable (in the Dart or JS sense) though? It's a struct. Also MobX/Vue-style stores (i.e. papering over pretty limited language support) are not the only way to handle mutability

  • @State is an attribute, otherwise known as an annotation in some languages (e.g. Dart), otherwise known as a very common thing in Swift code. If you mean what it does, even without looking at the docs it most likely marks a property as state that will change over time.

  • body is a computed property, which is readily apparent to Swift developers. As for when it's recomputed, does Widget build(BuildContext context) also inherently tell you when it's called again?

  • Content (again quite clearly to Swift developers) extends/implements View, which is where you'd look for answers to your question (it actually has a very nice API reference page).

  • This is pretty much "why is the keyword in this language not the same thing as the keyword in the language I use", not anything particularly "magical". The in keyword here is not the same thing as a for...in construct - it indicates that the body of a closure is about to begin. { item in ... } is a function block passed to the List constructor; a ListView's itemBuilder, if you will.

  • Are you legitimately asking why a view has its own encapsulated layout rules?

@cbazza
Copy link

@cbazza cbazza commented Jun 4, 2019

On SwiftUI:

1-Nice to see state declared in the View and not as a side appendage.

2-Nice individual methods to set things instead of having to pass everything on the constructor (methods enable actions to take in effect instead of just data being passed in).

3-Very nice to see declarative vector graphics mixed in with everything else that is declarative (like I suggested in the past with declarative SVG like widgets) !!!
https://developer.apple.com/tutorials/swiftui/drawing-paths-and-shapes

4-Very simple animation & transition constructs
https://developer.apple.com/tutorials/swiftui/animating-views-and-transitions

5-Drag&Drop design tools in synch with code editor both ways.

There are warts as everything else but I rather focus on what they did very nicely.

@rrousselGit
Copy link
Contributor

@rrousselGit rrousselGit commented Jun 4, 2019

These "questions" exists just to showcase potentially confusing points. These are not actual questions.

That might be because of your backgroung

Likely. I'm not saying that their approach is bad or anything. I'm saying it didn't feel natural to me as it did with Flutter.
Flutter widgets use almost no "fancy language feature" and could be implemented on nearly any languages (although the recent if/for for collections change that).
While their showcase of SwiftUI extensively uses Swift specific features.

As for when it's recomputed, does Widget build(BuildContext context) also inherently tell you when it's called again?

My point here is the lack of relationship between State and the act of recomputing body.
React and Flutter are very explicit on that matter: setState.
Vue/Mobx are "magical", using the same @State feature.

It's fine really, but that's a different pattern.

Are you legitimately asking why a view has its own encapsulated layout rules?

No, it's more of an "explicit" vs "implicit".
It seems that they really focused on "doing as much as possible in as little code as possible", even if it hides some of the logic (in that case, the ltr vs rtl logic)

Flutter would ask you to use a Row.

@filleduchaos
Copy link
Contributor

@filleduchaos filleduchaos commented Jun 4, 2019

Flutter uses and relies on plenty of "fancy language features" (read: language features that whoever the speaker is isn't used to and/or does not agree with). Just off the top of my head, constant constructors (and Dart's style of naming constructors in general), operator overloading, classes being implicit interfaces, @covariant, and mixins are features that would draw reactions from confusion to outright labeling as a code smell depending on a developer's background. I could probably come up with a longer list given an hour's thought. And that's not an indictment of Flutter any more than it's an indictment of SwiftUI - I don't see why one would think it's a virtue to write software in a particular language so that it could be written the same way in any language - what's the point of different languages if we're supposed to pretend like differences between them don't exist?

Besides, I completely disagree that either of setState or @State is explicit about its relationship with the act of rebuilding a view. In both cases you're simply told that if you change something that's been marked as state the framework will sort out what to build. In both cases the dev still has no explicit control over what's going on or when exactly. You find a function call more familiar, people who work in some other languages find decorators more familiar. But calling a function doesn't make things not magic.

Flutter would ask you to use a Row

I take it you've never used ListTile, which has the same behaviour shown here but with named parameters? Should we also ask why a Scaffold "magically" puts a menu button in the left of your appbar when you didn't ask it to?

@rrousselGit
Copy link
Contributor

@rrousselGit rrousselGit commented Jun 4, 2019

The difference is that in the current state of Dart is very similar to most mainstream languages.

That's important.
The question "Do I need to learn Dart, or can I just start learning Flutter?" comes up quite often.
At the moment, the answer is "just learn Flutter. You can write effective dart after a single day".
That's not guaranteed to stay this way forever, but I do think that this is one of the strength of Flutter.

The rest of the discussion is a bit off-topic. If you want we can continue that part by mail (my github mail works).

@naiveai
Copy link

@naiveai naiveai commented Jun 19, 2019

Why is this not locked? This is already devolving badly, and it's exactly the same as a locked issue earlier.

@lock
Copy link

@lock lock bot commented Apr 25, 2020

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

@lock lock bot locked and limited conversation to collaborators Apr 25, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet