cc @lukechurch

@cbazza 왜 이것을 원하는지 자세히 설명해 주시겠습니까? 오늘날과 비교했을 때 어떤 모습일지 예를 들어 보여 주시겠습니까?

좋습니다. ' https://flutter.io/widgets-intro/#basic -widgets'의 "기본 위젯" 예제는 다음과 같습니다.

import 'package:flutter/material.dart';

class MyAppBar extends StatelessWidget {
  MyAppBar({this.title});

  // Fields in a Widget subclass are always marked "final".

  final Widget title;

  <strong i="7">@override</strong>
  Widget build(BuildContext context) {
    let style = {
        height: 56.0, // in logical pixels
        padding: const EdgeInsets.symmetric(horizontal: 8.0),
        decoration: <BoxDecoration color={Colors.blue[500]}/>,
    };

    return <Container style={style}>
      <Row>
        <IconButton
            icon={<Icon name={Icons.menu}/>}
            tooltip='Navigation menu'
            onPressed={null}
        />
        <Expanded>
           {title}
    </Expanded>  
        <IconButton
            icon={<Icon name={Icons.search}/>}
            tooltip='Search'
            onPressed={null}
        />
      </Row>
    </Container>;
  }
}

class MyScaffold extends StatelessWidget {
  <strong i="8">@override</strong>
  Widget build(BuildContext context) {
    // Material is a conceptual piece of paper on which the UI appears.
    return <Material>
      <Column>
          <MyAppBar
             title={<Text 
               text='Example title'
               style={Theme.of(context).primaryTextTheme.title},
             />}
          />
          <Expanded>
            <Center>
              <Text text='Hello, world!'/>
            </Center>
          </Expanded>
      </Column>
    </Material>;
  }
}

void main() {
  runApp(<MaterialApp
    title='My app'
    home={<MyScaffold/>}
  />);
}

이 구문은 어떻습니까?:

import 'package:flutter/material.dart';

class MyAppBar extends StatelessWidget {
  MyAppBar({this.title});

  // Fields in a Widget subclass are always marked "final".

  final Widget title;

  <strong i="6">@override</strong>
  Widget build(BuildContext context) {
    return Container(
      height: 56.0, // in logical pixels
      padding: EdgeInsets.symmetric(horizontal: 8.0),
      decoration: BoxDecoration(color: Colors.blue[500]),
      child: Row(
        children: <Widget>[
          IconButton(
            icon: Icon(Icons.menu),
            tooltip: 'Navigation menu',
            onPressed: null,
          ),
          Expanded(
            child: title,
          ),
          IconButton(
            icon: Icon(Icons.search),
            tooltip: 'Search',
            onPressed: null,
          ),
        ],
      ),
    );
  }
}

class MyScaffold extends StatelessWidget {
  <strong i="7">@override</strong>
  Widget build(BuildContext context) {
    // Material is a conceptual piece of paper on which the UI appears.
    return Material(
      child: Column(
        children: <Widget>[
          MyAppBar(
            title: Text(
              'Example title',
              style: Theme.of(context).primaryTextTheme.title,
            ),
          ),
          Expanded(
            child: Center(
              child: Text('Hello, world!'),
            ),
          ),
        ],
      ),
    );
  }
}

void main() {
  runApp(MaterialApp(
    title: 'My app',
    home: MyScaffold(),
  ));
}

흠, 조금 개선되었지만 그다지 좋지는 않습니다 ...
다음은 XML을 사용하여 얻을 수 있는 사항입니다.
(1) 더 이상 '아동' 및 '아동' 물건 없음
(2) 제3자 도구가 조작하기 쉽습니다(분석, 분석 및 재생성).
(3) 마크업과 프로그래밍 간의 전환이 쉽게 감지됩니다. 내 말은 XML 내부에는 코드를 구분하는 '{}'가 있고 코드에는 ' 또한 주요 구조에서 모든 '스타일'을 분리하십시오.
나는 이것이 기본적으로 React의 방식을 완전히 지지한다는 것을 알고 있지만 어쨌든 절반은 왔습니다 ;)

cc @kasperl

(1) 더 이상 '아동' 및 '아동' 물건이 아닙니다.

그게 왜 바람직한지 잘 이해가 안됩니다. "어린이"와 "어린이"는 특별하지 않습니다. 예를 들어 ListTile을 고려하십시오. 어떻게 하시겠습니까? IconButton의 "아이콘" 또는 MaterialApp의 "홈"이 이름을 지정하고 싶지만 Expanded의 "자식"이 아닌 이유는 무엇입니까? 세 가지 모두 위젯 개체를 가져오는 임의의 인수일 뿐입니다. "아이" 대 "집"에 대해 마법 같은 것은 없습니다.

(2) 제3자 도구가 조작하기 쉽습니다(분석, 분석 및 재생성).

Dart 코드를 구문 분석, 분석 및 재생성할 수 있습니다. 그러나 우리가 그것을 더 쉽게 만들어야 한다는 데 동의합니다. 바라건대 앞으로 Dart 팀은 이를 위해 더 나은 API를 제공할 것입니다.

(3) 마크업과 프로그래밍 간의 전환이 쉽게 감지됩니다.

그것이 왜 바람직한가? 내 말은, 이 중 하나가 "프로그래밍"으로 간주되는 이유는 무엇입니까? 모두 표현일 뿐입니다.

내 말은 XML 내부에는 코드를 구분하는 '{}'가 있고 코드에는 '

구분이 잘 안되네요.

또한 모든 '스타일'을 주요 구조에서 분리하십시오.

정말 원하신다면 오늘 Flutter에서 이 작업을 수행할 수 있습니다. XML의 경우처럼 변수에 스타일을 넣으면 됩니다.

그게 왜 바람직한지 잘 이해가 안됩니다. "어린이"와 "어린이"는 특별하지 않습니다. 예를 들어 ListTile을 고려하십시오. 어떻게 하시겠습니까? IconButton의 "아이콘" 또는 MaterialApp의 "홈"이 이름을 지정하고 싶지만 Expanded의 "자식"이 아닌 이유는 무엇입니까? 세 가지 모두 위젯 개체를 가져오는 임의의 인수일 뿐입니다. "아이" 대 "집"에 대해 마법 같은 것은 없습니다.

덜 상용구, 구조에서 상속되기 때문에 말할 필요가 없습니다.

그것이 왜 바람직한가? 내 말은, 왜 이것이 "프로그래밍"으로 간주됩니까? 모두 표현일 뿐입니다.

도구 제작자, 특히 GUI 제작자가 Dart를 완전히 구문 분석할 필요가 없기 때문에 훨씬 쉽게 작업할 수 있기 때문에 (2)와 관련이 있습니다. 그러나 또한 코드를 더 쉽게 읽을 수 있습니다.

구분이 잘 이해가 안가네요.

XML 형식은 매우 간단하므로 '{}'가 표시되면 다트에서 표현식을 계산하고 있음을 알 수 있습니다. 반대의 경우도 마찬가지입니다. 다트 코드를 읽을 때 ') 개체 계층이 XML 마크업에서 생성된다는 것을 알고 있습니다.

또한 최종 XML 프로세서에서 부모의 속성에 개체를 전달하는 것을 피하고 대신 아래와 같이 자식 태그를 만듭니다.

this...
          <MyAppBar>
             <Title style={Theme.of(context).primaryTextTheme.title}>  
                 Example title
             </Title>
          </MyAppBar>

instead of this...
          <MyAppBar
             title={<Text 
               text='Example title'
               style={Theme.of(context).primaryTextTheme.title},
             />}
          />

덜 상용구, 구조에서 상속되기 때문에 말할 필요가 없습니다.

그러나 왜 일부 속성에만 해당합니까? ListItem과 같이 자식 슬롯이 두 개인 경우 어떻게 처리합니까? XML-ish 구문은 이것을 잘 처리하지 못하는 것 같습니다.

또한 나는 그것이 덜 상용구인지 확실하지 않습니다.

비교하다:

   <Container style={style}>
      <Row>
        <IconButton
            icon={<Icon name={Icons.menu}/>}
            tooltip='Navigation menu'
            onPressed={null}
        />
        <Expanded> {title} </Expanded>  
      </Row>
    </Container>

   Container(style: style,
      child: Row(
        children: [
          IconButton(
            icon: Icon(Icons.menu),
            tooltip: 'Navigation menu',
            onPressed: null,
          ),
          Expanded(child: title),
        ],
      ),
    )

XML 형식의 구문이 더 깔끔하거나 덜 상용적인지는 나에게 전혀 명확하지 않습니다. 더 많은 구두점과 내용의 일부 중복이 있습니다(예: 닫기 태그). 그리고 이름을 추가해야 했기 때문에 "자식"을 잃게 되지만 Icon에서 "이름"을 얻습니다.

또한 XML을 사용하여 Row는 0, 1 또는 2개 이상의 자식을 가질 수 있지만 Center는 정확히 하나의 자식을 가져야 함을 어떻게 분명히 합니까? 누군가 이렇게 하면 어떻게 될까요?:

   <Center> <Test/> <Test/> </Center>

도구 제작자, 특히 GUI 제작자가 Dart를 완전히 구문 분석할 필요가 없기 때문에 훨씬 쉽게 작업할 수 있기 때문에 (2)와 관련이 있습니다.

하지만 Dart 구문 분석 API가 있다면 Dart를 완전히 구문 분석할 필요가 없겠죠? 내 말은, 당신은 당신이 파싱하고 싶은 것을 파싱하고 나머지는 남겨둘 것입니다. 또한 실제로 XML이 아니기 때문에 실제로 구문 분석이 더 쉬운지 잘 모르겠습니다. 아래를 참조하십시오.

그러나 또한 코드를 더 쉽게 읽을 수 있습니다.

나는 여기에 있는 XMLy 버전이 더 읽기 쉽다고 확신하지 않습니다. 몇 가지 빌드 함수를 읽고 나면 중첩 생성자 구문에 빠르게 익숙해집니다.

XML의 형식은 매우 간단하므로 '{}'가 표시되면 다트에서 표현식을 계산하고 있음을 알 수 있습니다.

그러나 실제로는 XML이 아닙니다. 그렇죠? XML의 일부 변형입니다. 잘 정의된 구문 분석 규칙이 있습니까? 예를 들어 이것이 유효한가요?

  <Test name={describe("}")}>

Dart를 구문 분석하지 않고 첫 번째 "}"가 속성 표현식의 끝이 아니라는 것을 어떻게 알 수 있습니까?

반대의 경우도 마찬가지입니다. 다트 코드를 읽을 때 ') 개체 계층이 XML 마크업에서 생성된다는 것을 알고 있습니다.

오늘 new 키워드도 보면 알겠죠? 또는 실제로 대문자로 된 단어가 표시될 때 위의 새로운 마크업 제안에서. 이것이 정말 XML의 이점입니까, 아니면 Dart보다 XML에 더 익숙합니까?

또한 최종 XML 프로세서에서 부모의 속성에 개체를 전달하는 것을 피하고 대신 아래와 같이 자식 태그를 만듭니다.

나는 당신이 여기서 제안하는 것을 정말로 이해하지 못합니다. 내가 말할 수 있는 한 이것은 잘 구성된 XML이 아닙니다. 제안하는 구문이 무엇이며 어떻게 작동하는지 정확히 설명할 수 있습니까? 예를 들어 "텍스트" 생성자가 사라진 것 같습니다. 프로세서가 그것을 어떻게 알 수 있습니까?

보세요, 당신은 내가 말하는 모든 것을 섞고 있고 이 대화는 아무데도 가지 않고 있습니다. 법적 용어로 당신은 "증인에게 덤벼드는" 것입니다.

JSX가 인기 있는 이유를 배우는 데 정말로 관심이 있다면 "react tutorial"을 검색하여 지난 2년 동안 React에 대한 모든 기사에서 JSX를 사용했습니다. React에서 구성 요소 계층 구조를 생성하는 원래 방법(Flutter의 현재 방법과 동일)은 JSX가 선호되는 방법(모범 사례)이 되었기 때문에 다시 언급되지 않습니다.

https://facebook.github.io/react/tutorial/tutorial.html
https://facebook.github.io/react-native/docs/flatlist.html

또 다른 흥미로운 점은 Typescript가 JSX도 채택했다는 것입니다.
https://www.typescriptlang.org/docs/handbook/jsx.html

XML 구문 분석('{}'을 올바르게 건너뛰는 추가 코드 포함)이 Dart와 같은 프로그래밍 언어를 완전히 구문 분석하는 것보다 훨씬 간단하다는 사실을 이해하지 못했습니다. 그것은 사실입니다. 도구 빌더가 개발에 Dart를 사용할 것이라고 가정하고 있습니다. Intellij는 Dart를 지원하는 IDE에서 Kotlin과 Java를 사용하고 있을 가능성이 큽니다(그들은 언어 구문 분석을 전문으로 하기 때문에 특별한 경우입니다. 다른 언어에서 Dart 구문 분석).

XML을 다른 언어에 넣는 것에 대해 내가 좋아하는 것은 XML이 프로그래밍 언어와 매우 다르기 때문에 둘 사이에 인지적 분리를 제공한다는 것입니다. 소스 파일을 스크롤하기만 하면 코드와 선언적 마크업이 무엇인지 쉽게 알 수 있습니다. 마크업인 척하는 다트 코드로는 이를 달성할 수 없습니다.

완전히 지정되지 않은 항목을 따지는 것을 중지하십시오. JSX에서 처리된 방법에 대해 자세히 알아보십시오. 여기 할 시간이 없어요.

내가 방어적이거나 공격적으로 들린다면 사과드립니다. 이것은 여러 번 나왔던 주제이지만 전에는 실제로 이 사건에 대해 논쟁을 벌이려는 사람이 없었기 때문에 이 대화가 요청의 근거가 무엇인지 가르치는 데 매우 유용하다는 것을 알게 되었습니다. 내 논쟁적인 어조를 무시하는 것으로 받아들이지 마십시오. 여기에 대한 귀하의 의견에 매우 관심이 있습니다.

답장을 보내야 한다고 생각하지 마시기 바랍니다. 어떤 식으로든 결정을 내리거나 디자인하기 전에 해결해야 하는 문제에 대한 투명성이 있기 위해 여기에 언급하는 것입니다. 이것은 기본적으로 그냥 소크라테스식 대화입니다. 귀하의 참여를 환영하지만 확실히 귀하의 제안을 옹호하는 것이 귀하의 책임이라고 생각해서는 안 됩니다.

JSX가 "핫"하다는 데는 의심의 여지가 없습니다. React에서 JSX가 아닌 구문은 이 문제에서 제안된 대체 구문(현재 코드처럼 보이지만 "new" 및 "const" 키워드가 없는 구문)보다 훨씬 나쁩니다. 내가 이해하려고 하는 것은 JSX가 React에서 "핫"한 것과 같은 이유가 Flutter에도 적용되는지 여부입니다.

TypeScript가 JSX를 수행하는 것과 관련하여 2012년에 E4H 를 지정하는 작업에 참여했으며 그 이전에도 E4X 가 있었습니다. 두 가지 노력 모두 죽었습니다. 따라서 사람들이 JSX와 다른 구문에 대해 정확히 어떤 관계인지 이해하는 것이 중요합니다.

XML을 구문 분석하는 것은 쉬운 일이 아니며 일종의 XML이지만 중괄호를 사용하여 구문 분석하는 것도 쉽지 않습니다. 일종의 XML이지만 중괄호가 있으면 어떻게든 다른 언어에 포함된 구문 분석은 훨씬 더 쉽습니다. 그러나 구현하기가 얼마나 쉬운지는 한 두 번 구현한 다음 이를 수행하는 라이브러리를 재사용할 것이기 때문에 아마도 큰 문제가 아닐 것입니다. (저는 HTML 구문 분석을 위한 사양 작성에 많이 관여했고 XML에 대한 유사한 작업에 참여했으며 Dart용 구문 분석기를 구현했기 때문에 마크업 언어와 프로그래밍 언어를 실제로 구문 분석하는 것이 얼마나 어려운지 잘 알고 있습니다. 이다.)

XML을 다른 언어에 넣는 것에 대해 내가 좋아하는 것은 XML이 프로그래밍 언어와 매우 다르기 때문에 둘 사이에 인지적 분리를 제공한다는 것입니다. 소스 파일을 스크롤하기만 하면 코드와 선언적 마크업이 무엇인지 쉽게 알 수 있습니다. 마크업인 척하는 다트 코드로는 이를 달성할 수 없습니다.

하지만 그렇게 할 수 있는 것이 유익한 이유는 무엇입니까?

빌드 기능이 있는 Flutter 앱을 스크롤할 때 매우 분명합니다(거대한 중첩 표현식). "코드"와 분리하는 것이 중요한 "선언적 마크업"은 무엇입니까?

완전히 지정되지 않은 항목을 따지는 것을 중지하십시오. JSX에서 처리된 방법에 대해 자세히 알아보십시오. 여기 할 시간이 없어요.

내가 말할 수 있는 한, JSX는 내가 요청한 것을 처리하지 않습니다. 예를 들어 React에는 자식 슬롯이라는 개념이 없습니다. 내가 찾을 수있는 가장 가까운 것은 JS로 다시 전환 한 다음 그 내부에서 JSX로 다시 전환하여 수행하는 작업이므로 프로그래밍 언어와 마크업 언어를 모두 구문 분석할 수 있어야 합니다.

내가 이해하려고 하는 것은 JSX가 React에서 "핫"한 것과 같은 이유가 Flutter에도 적용되는지 여부입니다.

예, 정확히 동일한 내용이 여기에 적용됩니다. 현재 방법이 당신에게 있는 유일한 옵션이기 때문에 당신에게 좋아 보입니다. 사람들에게 두 번째 옵션을 제공하면 동일한 일이 발생할 것입니다.

영원한 것은 없기 때문에 E4X가 죽었는지 아닌지는 중요하지 않습니다. 저는 E4X와 함께 ActionScript를 많이 사용했으며 Adobe가 거기에서 훌륭한 일을 했다고 생각했습니다. 어떤 면에서 Flutter는 Flex 앱이 포함된 Adobe Flash의 최신 버전일 뿐입니다.

(저는 HTML 구문 분석을 위한 사양 작성에 많이 관여했고 XML에 대한 유사한 작업에 참여했으며 Dart용 구문 분석기를 구현했기 때문에 마크업 언어와 프로그래밍 언어를 실제로 구문 분석하는 것이 얼마나 어려운지 잘 알고 있습니다. 이다.)

마크업 언어를 구문 분석하는 것이 명령형 프로그래밍 언어를 구문 분석하는 것과 비교하면 간단하다는 것을 알 수 있습니다.

하지만 그렇게 할 수 있는 것이 유익한 이유는 무엇입니까?

코드 가독성과 단순성은 다른 많은 이점을 가져다줍니다.

빌드 기능이 있는 Flutter 앱을 스크롤할 때 매우 분명합니다(거대한 중첩 표현식). "코드"와 분리하는 것이 중요한 "선언적 마크업"은 무엇입니까?

거대한 중첩 표현식에서 구조를 쉽게 볼 수 있습니까? 이 구조는 GUI 빌더와 같은 다른 도구로 쉽게 조작할 수 있습니까? Adobe Flex Builder가 위젯을 드래그 앤 드롭하는 데 사용하는 것처럼 UI에 연결한 다음 코드 보기로 전환하고 원하는 모든 것을 편집한 다음 GUI 모드로 다시 전환하고 위젯을 계속 조작합니다. 프로그래머가 "거대한 중첩 표현식" 내부로 들어가서 GUI 편집기가 기대하는 구조를 따르지 않는 유효한 다트 코드를 작성할 때 쉽게 할 수 없습니다. 문제가 되지 않는 고정된 XML 구조를 사용합니다.

내가 말할 수 있는 한, JSX는 내가 요청한 것을 처리하지 않습니다. 예를 들어 React에는 자식 슬롯이라는 개념이 없습니다.

그것은 잘 처리합니다. 당신은 그것을하는 방법을 모릅니다. 따라서 앞으로 여기에 문제의 예를 넣으면 JSX 버전이 어떠해야 한다고 생각하는지 알려 드리겠습니다.

  new ListTile(
    title: new Text('CineArts at the Empire',
        style: new TextStyle(fontWeight: FontWeight.w500, fontSize: 20.0)),
    subtitle: new Text('85 W Portal Ave'),
    leading: new Icon(
      Icons.theaters,
      color: Colors.blue[500],
    ),
  ),

  <ListTile>
    <title> 
      <Text style={{fontWeight: FontWeight.w500, fontSize: 20.0}}>
         CineArts at the Empire
      </Text>
    </title>
    <subtitle>
      <Text>85 W Portal Ave</Text>
    </subtitle>
    <leading>
      <Icon data={Icons.theaters} color={Colors.blue[500]}/>
    </leading>
  </ListTile>,

다트 버전보다 더 길어 보이지만 같은 줄 수에 모든 것을 배치할 수 있었습니다. 문제는 IDE/편집기가 '+' 및 '-'를 제공하여 이러한 XML 노드를 어쨌든 확장 및 축소할 수 있다는 것입니다.

Flutter를 React 개발자에게 친숙하게 보이게 하면 많은 새로운 사용자를 Flutter로 끌어들일 수 있습니다.

영원한 것은 없기 때문에 E4X가 죽었는지 아닌지는 중요하지 않습니다.

죽었느냐가 문제가 아니라 왜 죽느냐가 문제다. 사람들이 원하는 솔루션을 제공하지 않아서 죽은 건가요? 구현 문제 때문에 죽었습니까? 특허 문제로 죽었을까? 너무 이른 시간이었나요? 너무 늦었어? 과거 경험에서 교훈을 얻는 것이 중요하다고 생각합니다. JSX가 성공한 곳에서 E4X 및 E4H가 실패한 이유는 무엇입니까?

흥미롭게도 Flutter를 처음 사용하는 사람들은 마크업 언어와 애니메이션 GIF라는 두 가지를 자주 요구합니다. 그리고 3개월이 지난 후에도 여전히 애니메이션 GIF를 요구하지만 마크업 언어는 요구하지 않습니다. Dart에서 빌드 메서드를 작성하는 데 익숙해지면 마크업 언어가 실제로 필요하지 않기 때문일 수 있습니다. 그들은 여전히 ​​마크업 언어를 원하지만 누락 문제를 해결했기 때문에 더 이상 묻지 않을 수도 있습니다. 그렇지 않으면 잘못된 선택(어느 쪽이든)에 노력을 들일 위험이 있기 때문에 어느 쪽을 알아낼 가치가 있습니다.

거대한 중첩 표현식에서 구조를 쉽게 볼 수 있습니까?

네, 최소한 XML만큼은 쉽습니다. 개인적으로 XML은 매우 장황하고 구조를 난독화합니다. 하지만 이것은 당신이 익숙해진 것에 관한 것입니다.

(또한 실제로 작성하지 않고도 구조를 볼 수 있도록 가상 "닫는 태그" 주석 을 입력하는 IDE를 실험하고 있습니다.)

마크업 언어를 구문 분석하는 것이 명령형 프로그래밍 언어를 구문 분석하는 것과 비교하면 간단하다는 것을 알 수 있습니다.

내 경험에 따르면 선언적 대 명령형은 언어가 얼마나 쉽게 구문 분석되는지 결정할 때 중요한 구분이 아닙니다. (예를 들어 HTML은 "선언적"이지만 내가 다루었던 것 중 구문 분석하기 가장 복잡한 언어 중 하나일 수 있습니다.)

코드 가독성과 단순성은 다른 많은 이점을 가져다줍니다.

이것이 주요 이점이라면 우리가 테스트할 수 있는 것입니다. HTML, React, iOS 코드, Android 코드, Flutter, 명령줄 앱 등을 작성하는 데 익숙한 엔지니어들을 혼합하여 다양한 구문으로 제시하고 그들이 생각하는 바를 설명하도록 요청할 수 있습니다. 결과 UI는 다음과 같습니다. 그런 다음 최상의 결과를 얻는 구문을 측정할 수 있습니다. @InMatrix 는 애니메이션 작업이 끝난 후 볼 수 있는 것입니까?

이 구조는 GUI 빌더와 같은 다른 도구로 쉽게 조작할 수 있습니까?

예, 적어도 원칙적으로. 기계적으로 Dart 표현식을 XML이나 JSON 또는 사용할 수 있는 다른 구조화된 언어로 변환하는 것은 비교적 간단해야 합니다. 구문을 변환하는 문제일 뿐이며 실제 정보는 동일합니다. 개인적으로 GUI 편집기를 만드는 경우 다른 구문으로 변환하지 않고 Dart에서 직접 메모리의 데이터 구조로 구문 분석합니다.

프로그래머가 "거대한 중첩 표현식" 내부로 들어가서 GUI 편집기가 기대하는 구조를 따르지 않는 유효한 다트 코드를 작성할 때 쉽게 할 수 없습니다. 문제가 되지 않는 고정된 XML 구조로.

문제는 Dart 표현식에서와 같이 XML 구조에 정확히 동일한 "모든 유효한 dart 코드"를 넣을 수 있다는 것입니다. 그들은 말 그대로 기계적으로 교환할 수 있습니다. 따라서 XML을 사용하는 것이 특히 도움이 되는지 잘 모르겠습니다. 예를 들어 이것을 XML로 어떻게 바꾸겠습니까?

new ListView.builder(
  padding: new EdgeInsets.all(8.0),
  itemExtent: 20.0,
  itemBuilder: (BuildContext context, int index) {
    return new Text('entry $index');
  },
)

그것은 잘 처리합니다. 당신은 그것을하는 방법을 모릅니다.

나는 특히 JSX를 의미했습니다. 귀하가 제안한 구문이 문제에 접근하는 데 완벽하게 유효한 방법이라는 데 동의합니다.

나는 지난 몇 년 동안 Adobe에 제품이 존재했던 XML 마크업과 ActionScript를 결합한 Adobe의 Flex SDK를 작업했습니다. UI 정의를 위한 마크업의 매력을 이해하지만 몇 가지 단점도 기억할 수 있습니다.

• Flex 애플리케이션 비주얼은 마크업과 코드로 정의할 수 있습니다. 내가 기억하는 바에 따르면 코드는 대규모 실제 앱에서 지배적인 경향이 있었습니다. 가독성은 마크업과 코드의 복잡한 하이브리드로 정의된 앱에 반드시 이점이 있는 것은 아닙니다.
• "Flex Builder" IDE는 마크업과 코드로 정의된 앱을 지원해야 했습니다. 이로 인해 IDE를 구축하고 유지 관리하기가 어려웠습니다. 개발자들은 이것을 ActionScript 도구로 보는 경향이 있습니다.
• XML "컴파일러"를 발전시키고 유지하는 것은 엔지니어 팀을 풀타임으로 바쁘게 만드는 상당한 부담이었습니다. 컴파일러와 툴킷을 잠금 상태로 유지하면 전체 SDK의 발전 속도가 느려졌습니다.

몇 년이 지났고 더 이상 모든 세부 사항을 기억할 수 없습니다. 그러나 전반적인 인상은 마크업과 코드의 조합으로 UI를 정의하는 것이 기껏해야 혼합 백이라는 것입니다.

죽었느냐가 문제가 아니라 왜 죽느냐가 문제다. 사람들이 원하는 솔루션을 제공하지 않아서 죽은 건가요? 구현 문제 때문에 죽었습니까? 특허 문제로 죽었을까? 너무 이른 시간이었나요? 너무 늦었어? 과거 경험에서 교훈을 얻는 것이 중요하다고 생각합니다. JSX가 성공한 곳에서 E4X 및 E4H가 실패한 이유는 무엇입니까?

E4X는 Adobe Flash/Flex 내에서만 사용되는 ActionScript에서만 구현되었고 Adobe는 프로젝트를 종료했기 때문에 종료되었습니다. 대신 Adobe는 종속 및 생태계 붕괴의 가능성이 있는 단일 소스 공급자가 없는 개방형 표준으로 방향을 변경했습니다.

흥미롭게도 Flutter를 처음 사용하는 사람들은 마크업 언어와 애니메이션 GIF라는 두 가지를 자주 요구합니다. 그리고 3개월이 지난 후에도 여전히 애니메이션 GIF를 요구하지만 마크업 언어는 요구하지 않습니다. Dart에서 빌드 메서드를 작성하는 데 익숙해지면 마크업 언어가 실제로 필요하지 않기 때문일 수 있습니다. 그들은 여전히 ​​마크업 언어를 원하지만 누락 문제를 해결했기 때문에 더 이상 묻지 않을 수도 있습니다. 그렇지 않으면 잘못된 선택(어느 쪽이든)에 노력을 들일 위험이 있기 때문에 어느 쪽을 알아낼 가치가 있습니다.

글쎄, 내가 당신에게 두 가지를 요청했는데 당신이 3개월 동안 아무것도 하지 않았고 첫 번째에 대한 대안이 있다면, 나는 또한 당신의 응답성과 이전 전달 실적을 감안할 때 완전히 불가능한 일에 대해서만 요청할 것입니다.

(또한 실제로 작성하지 않고도 구조를 볼 수 있도록 가상 "닫는 태그" 주석을 입력하는 IDE를 실험하고 있습니다.)

좀 웃기긴 하지만 앞에서 언급한 XML 닫는 태그를 넣는 것이 너무 장황한 것과 같습니다.

이것이 주요 이점이라면 우리가 테스트할 수 있는 것입니다. HTML, React, iOS 코드, Android 코드, Flutter, 명령줄 앱 등을 작성하는 데 익숙한 엔지니어들을 혼합하여 다양한 구문으로 제시하고 그들이 생각하는 바를 설명하도록 요청할 수 있습니다. 결과 UI는 다음과 같습니다. 그런 다음 최상의 결과를 얻는 구문을 측정할 수 있습니다. @InMatrix 는 애니메이션 작업이 끝난 후 볼 수 있는 것입니까?

물론 계속 진행할 수 있습니다. "한 번 React(JSX 사용)를 수행하면 다시 돌아가지 않습니다."라는 것을 알게 될 것이라고 확신합니다. 경험 많은 React 개발자를 대상으로 설문조사를 하고 JSX가 나쁘고 절대 하지 말았어야 했다고 생각하는지 물어보십시오. 당신의 길을 보여주고 그들이 JSX를 당신이 가지고 있는 것으로 교체하고 싶은지 물어보십시오. 그렇게 하기 전에 문을 닫고 장소를 잠그십시오. 이 개발자들은 물건을 들고 가장 가까운 출구를 향해 질주할 것이기 때문입니다.

문제는 Dart 표현식에서와 같이 XML 구조에 정확히 동일한 "모든 유효한 dart 코드"를 넣을 수 있다는 것입니다.

물론, 하지만 GUI 빌더에게는 건드릴 필요가 없고 쉽게 건너뛸 수 있는 바이트 블록일 뿐입니다. 설계/코드 호환성을 원칙 대신에 실질적으로 가능하게 만듭니다.

new ListView.builder(
  padding: new EdgeInsets.all(8.0),
  itemExtent: 20.0,
  itemBuilder: (BuildContext context, int index) {
    return new Text('entry $index');
  },
)

let style = {
  padding: new EdgeInsets.all(8.0),
  itemExtent: 20.0
};

<ListView.builder style={style}>
  {(context, index) => <Text> entry {index} </Text>}
</ListView.builder>

Adobe Flex Builder를 광범위하게 사용했는데...

개발자들은 이것을 ActionScript 도구로 보는 경향이 있습니다.

예, 하지만 종종 디자인 보기에서 코드 보기로 또는 그 반대로 전환했습니다.
화면을 시작하면 디자인 보기로 이동하고 드래그/드롭을 사용하여 위젯을 레이아웃하고 첫 번째 정적 화면을 생성합니다. 그런 다음 코드와 일부 정적 데이터를 추가하여 화면을 채우고 프로덕션 준비가 된 것처럼 보이는 실행 중인 것을 사람들에게 보여줄 수 있습니다. 생산성은 놀라웠습니다. 개발이 진행되면서 프론트 엔드를 백엔드에 연결했고 ActionScript 코드의 양이 증가했고 예, 코드 전체를 지배했지만 릴리스 시간이 가까워졌음에도 불구하고 디자인 보기를 사용하여 자세히 알아보지 않고도 UI를 조정하는 경우가 많았습니다. 암호.

그러나 전반적인 인상은 마크업과 코드의 조합으로 UI를 정의하는 것이 기껏해야 혼합 백이라는 것입니다.

요즘 세상에 없습니다. 명령형 언어는 Python 철학에서 발전했으며 개발에 적합합니다. 임베디드 마크업(XML)을 사용한 선언적 기술은 React의 출현으로 주류가 되었습니다. JSON은 선호하는 텍스트 기반 데이터 형식이 되었습니다.

E4X는 ActionScript에서만 구현되었습니다.

E4X는 ECMA 표준이었습니다. Mozilla는 잠시 동안 이를 제공했지만 제거했습니다(브라우저 공급업체로서는 매우 이례적인 움직임). 다른 브라우저 공급업체는 이를 구현하기를 원하지 않았습니다. (하지만 그들은 다른 새로운 ECMA 기능을 구현했습니다.) E4H를 사용하여 브라우저 공급업체는 구현에 전혀 관심이 없었습니다.

글쎄, 내가 당신에게 두 가지를 요청했는데 당신이 3개월 동안 아무것도 하지 않았고 첫 번째에 대한 대안이 있다면, 나는 또한 당신의 응답성과 이전 전달 실적을 감안할 때 완전히 불가능한 일에 대해서만 요청할 것입니다.

그것은 하나의 가능한 이론입니다. 그러나 사람들은 그 외에도 많은 것을 요구하는 경향이 있으며, 그들이 요구하는 많은 것들이 구현되고 애니메이션 GIF에 대한 해결 방법도 있으므로 이것이 상황을 완전히 설명하는지 확신할 수 없습니다.

좀 웃기긴 하지만 앞에서 언급한 XML 닫는 태그를 넣는 것이 너무 장황한 것과 같습니다.

물론. 이것은 선택적 IDE 기능이며 코드에 작성할 필요가 없으므로 자세한 정보가 문제인지 여부에 큰 차이가 있습니다.

... ListView ...

GUI 편집기는 이 마크업을 어떻게 처리할까요? 나는 이것을 위해 UI를 시각화하는 방법을 정말로 이해하지 못합니다.

이것은 이 요청에 대한 반론일 수 있으며/또는 마크업을 원하는 경우 염두에 두어야 할 통찰력이 있을 수 있습니다. 나는 다른 API가 통과하는 것을 보고 싶지 않은 GWT와 함께 몇 가지 문제를 만드는 마크업을 추가한다는 강한 느낌을 가지고 있습니다.

UI 구축과 관련하여 몇 가지 다른 프레임워크가 이러한 전환을 거치는 것을 보았습니다. 이와 같은 마크업은 도구에 매우 적합하며 지금까지 IDE 개발자에게는 천국과 같은 것입니다. 누가 무엇을 하는지에 대한 책임을 분리하는 것이 더 쉽습니다. 더 잘할 수 있다고 생각하지만.

GWT는 이러한 방식으로 시작하여 Java로 UI를 구축했습니다. 그런 다음 사양과 함께 xml 마크업에서 UI를 빌드할 수 있는 UiBinder가 제공되었습니다. 그런 다음 도구인 Eclipse 플러그인은 xml 마크업에서 UI를 생성할 수 있었습니다. Android도 그렇게 하고 있으므로 요점을 설명할 필요가 없습니다. 그래서 내가 본 결과, 마크업은 UI IDE 개발자들에게 훌륭하게 작동합니다. 그러나 실제로 마크업은 엄청난 시간 투자이며 실제 프로그램으로 전환하기 위해 복잡한 도구를 추가합니다. 그리고 도구는 항상 마지막에 나옵니다. 그래서 그 동안 모든 것이 현실로 나타나는 동안 두 개의 세계가 있습니다. 모든 일을 하는 두 가지 흥미로운 방법. 하나는 기본 언어이고 하나는 마크업입니다. 그래서 저는 오늘 GWT를 지지합니다. 문서를 작성할 때 Java용으로 한 번, UiBinder XML 마크업용으로 한 번, 두 번 작성해야 합니다. 따라서 실제 질문은 마크업 길을 가고 싶다면 질문을 해야 한다고 생각합니다. 추가된 복잡성은 여행의 가치가 있다는 것입니다!

JSX는 HTML과 자바스크립트로 하는 일을 함께 혼합하려는 다른 문제를 해결하는 것을 목표로 한다고 생각합니다. 마크업 사양의 추가된 복잡성이 마크업으로 UI를 작성하는 요구 사항에 적합하다고 느껴지지 않습니다. 특히 문서 마크업 언어를 대상으로 하지 않는 경우에는 더욱 그렇습니다. 적어도 일상적인 사용자에게는 그렇지 않습니다.

긍정적 인 메모에. 나는 도구로 일하는 것을 좋아합니다. 따라서 마크업 언어가 상당히 유용하다는 것을 알 수 있습니다. 마크업을 사용할 때 AST를 작성하고 수정하는 것이 훨씬 쉽습니다.

하지만 다시 말하지만, 당신이 일에 대해 충분한 마음을 가지고 있다면, 당신이 무엇을 하든 별로 중요하지 않습니다. 결국 개발자가 API를 사용하여 애플리케이션을 더 빠르게 작성할 수 있다면 관심을 끌 것입니다. 그러나 엔지니어링 팀의 비용은 얼마입니까?

진짜 질문은 UI를 더 빠르게 구축할 수 있는 방법이라고 생각합니다. 도구로 다트를 작성하고 중간 마크업을 건너뛸 수 있다고 생각합니다. 그리고 제 목표는 그것이 가치가 없다고 말하는 것이 아니라 길을 택한다면 모든 면에서 비용을 실제로 계산하는 것입니다!

E4X는 ECMA 표준이었습니다. Mozilla는 잠시 동안 이를 제공했지만 제거했습니다(브라우저 공급업체로서는 매우 이례적인 움직임). 다른 브라우저 공급업체는 이를 구현하기를 원하지 않았습니다.

Adobe만이 E4X를 완벽하게 옹호했으며 개발자들에게 좋은 평판을 얻었습니다. 브라우저 공급업체는 항상 브라우저에서 항목을 추가 및 제거합니다. Google이 MathML 지원을 제거하지 않았습니까?

그것은 하나의 가능한 이론입니다. 그러나 사람들은 그 외에도 많은 것을 요구하는 경향이 있으며, 그들이 요구하는 많은 것들이 구현되고 애니메이션 GIF에 대한 해결 방법도 있으므로 이것이 상황을 완전히 설명하는지 확신할 수 없습니다.

다음은 React와 JSX에 관한 것입니다. 보았고 잠시 동안 개발할 때까지 React가 테이블에 제공하는 것을 완전히 이해하지 못했습니다. 다른 모든 프레임워크에 대해 하루.

GUI 편집기는 이 마크업을 어떻게 처리할까요? 나는 이것을 위해 UI를 시각화하는 방법을 정말로 이해하지 못합니다.

let style = {
  padding: new EdgeInsets.all(8.0),
  itemExtent: 20.0
};

<ListView.builder style={style}>
  {(context, index) => <Text> entry {index} </Text>}
</ListView.builder>

나는 \직사각형으로 그리고 다른 위젯이 있는 자식/자식이라면 그 안에 직사각형을 넣을 것입니다.
이 경우 자식은 함수이므로 '편집 불가/코드'라는 사각형을 넣어 사용자에게 이 위젯이 코드에서 생성되었음을 알리거나 이 경우 함수가위젯을 만들고 간단히 제시하십시오. 함수가 얕은 함수 래퍼이고 그 안에 목록 항목 위젯 사각형(\이 경우).

그러나 실제로 마크업은 엄청난 시간 투자이며 실제 프로그램으로 전환하기 위해 복잡한 도구를 추가합니다.

내가 요구하는 것은 개발자가 원할 경우 이 XML 구조를 사용하여 작성할 수 있도록 Dart 컴파일러에 이러한 간단한 확장을 추가하는 것입니다. 기존 방식은 계속 작동할 것이며 이를 수행하는 데 필요한 작업량은 그다지 크지 않습니다. 실제로 babel.js 컴파일러가 JSX를 수행하는 데 몇 줄의 코드가 필요한지 알 수 있습니다. 저는 수천 줄이 아니라 수백 줄을 말하고 있습니다(방금 확인했습니다).

그리고 도구는 항상 마지막에 나옵니다. 그래서 그 동안 모든 것이 현실로 나타나는 동안 두 개의 세계가 있습니다. 모든 일을 하는 두 가지 흥미로운 방법. 하나는 기본 언어로, 하나는 마크업으로

물론입니다. 하지만 React는 이와 같았으며 전혀 문제가 되지 않습니다.

문서를 작성할 때 Java용으로 한 번, UiBinder XML 마크업용으로 한 번, 두 번 작성해야 합니다.

마크업이 코드 내부에 있기 때문에 React에는 없습니다.

추가된 복잡성은 여행의 가치가 있습니다!

물론 개발자에게 최신 기술을 교육하고 회사를 떠날 위험을 감수해야 하는지 여부에 대한 논쟁과 같습니다. 더 큰 위험은 훈련되지 않은 상태로 유지하는 것입니다. 따라서 최신 기술을 채택하지 않으면 뒤처질 위험이 있습니다.

React는 UI/UX 개발을 위한 최신 기술로 여정을 주도하고 있습니다. 개발자들에게 엄청난 관심을 받고 있습니다. 가장 큰 위험은 React bar를 만나지 않는 것입니다.

JSX 내 생각에는 HTML과 자바스크립트로 하는 일을 함께 혼합하려는 다른 문제를 해결하는 것이 목표라고 생각합니다.

JSX는 HTML용이 아닙니다. React Native는 XML 마크업에서 보기(예: Flutter 위젯)를 생성합니다.

진짜 질문은 UI를 더 빠르게 구축할 수 있는 방법이라고 생각합니다.

UI/UX를 더 잘 구축할 수 있는 방법과 비슷합니다. 더 나은 의미: 더 빠르고 더 높은 품질(코드 및 UI/UX), 부드러운 디자이너-개발자 상호 작용 등

그건 그렇고, 개발자 도구에서 정말 멋진 일을 했습니다. '플러터닥터' 굉장했어!!!
나는 지금 가스로 요리하고 있고 위험할 정도로 창의적일 수 있습니다 ;)

나는 가독성이 우리가 고려해야 할 많은 요소 중 하나일 뿐이라는 것을 이해하지만 여기에서 제기된 가독성 질문에 답하고 싶었습니다.

코드 가독성과 단순성은 다른 많은 이점을 가져다줍니다.

이것이 주요 이점이라면 우리가 테스트할 수 있는 것입니다. HTML, React, iOS 코드, Android 코드, Flutter, 명령줄 앱 등을 작성하는 데 익숙한 엔지니어들을 혼합하여 다양한 구문으로 제시하고 그들이 생각하는 바를 설명하도록 요청할 수 있습니다. 결과 UI는 다음과 같습니다. 그런 다음 최상의 결과를 얻는 구문을 측정할 수 있습니다. @InMatrix 는 애니메이션 작업이 끝난 후 볼 수 있는 것입니까?

확실히 코드 가독성을 실험적으로 연구할 수 있는 방법이 있으며, 4분기 계획이 필요할 때 더 진지하게 논의할 수 있습니다. 그러한 연구를 유용하게 만들려면 Flutter 프로그래밍의 맥락에서 개발자에게 어떤 종류의 읽기 작업이 중요한지 정의해야 합니다. 전체 빌드 방법을 읽고 결과 UI가 무엇인지 그리는 것 외에도 가독성은 다트 파일에서 빌드 방법 식별, 중괄호 일치, 인라인 주석 읽기 등과 같은 작은 작업에도 영향을 미칩니다.

보다 좁은 범위의 작업 중 일부를 지원하기 위해 먼저 편집기에서 UI 향상을 실험할 수 있습니다. 이는 일반적으로 마크업 언어를 도입하고 유지 관리하는 것보다 저렴합니다. VS 코드의 닫는 레이블 기능은 UI 개선 사항 중 하나이며 해결하려는 중괄호 일치 문제를 얼마나 잘 해결하는지 이해해야 합니다. 이 공간에는 아직 시도하지 않은 다른 옵션이 많이 있습니다. 예를 들어 다른 글꼴이나 배경색을 사용하여 개발자가 코드의 나머지 부분과 정신적으로 분리하는 데 도움이 되도록 빌드 메서드를 표시할 수 있습니다.

나를 중요하게 생각하는 또 다른 것은 사람들이 거대한 빌드 방법을 작성하지 않고 프레임워크의 구성 특성을 활용하도록 권장할 수 있는 방법입니다. 빌드 방법이 화면 높이보다 높으면 Dart든 XML이든 읽기 어려울 것입니다.

나를 중요하게 생각하는 또 다른 것은 사람들이 거대한 빌드 방법을 작성하지 않고 프레임워크의 구성 특성을 활용하도록 권장할 수 있는 방법입니다. 빌드 방법이 화면 높이보다 높으면 Dart든 XML이든 읽기 어려울 것입니다.

빌드 방법뿐만이 아닙니다. 빌드 메소드가 위젯 트리를 빌드하기 위해 호출하는 것은 다른 모든 메소드입니다. 하위 트리 조각을 빌드하고 더 큰 트리로 호출하기 위해 더 작은 방법을 사용하는 것은 React에서 매우 일반적입니다.

또한 WebStorm with JSX에서 각 XML 노드에는 노드를 확장/축소하는 데 사용할 수 있는 +/-가 있고 화면 높이보다 큰 구조를 쉽게 읽을 수 있도록 노드와 자식을 사용할 수 있습니다.

Flutter에서 우리가 발견한 한 가지는 큰 빌드 방법이 성능에 좋지 않다는 것입니다. 우리는 사람들이 빌드 방법을 더 작은 재사용 가능한 위젯으로 분해하도록 권장하려고 노력합니다. 특히 Flutter에서 다른 방법의 결과로 빌드된 방법을 사용하는 것은 우리가 더 쉽게 만들기보다는 오히려 권장하지 않는 일종의 반패턴입니다. (이것은 최근에 깨달은 것이므로 많은 예제와 위젯이 아직 제대로 하지 못하고 있습니다.)

우리는 사람들이 빌드 방법을 더 작은 재사용 가능한 위젯으로 분해하도록 권장합니다.

실제로 재사용 가능한 위젯이 됩니까? 아니면 단순히 래퍼/복합 위젯이 됩니까? 재사용 가능하려면 최소 2개의 사용 인스턴스가 있어야 합니다.

https://flutter.io/catalog/samples/basic-app-bar/ 의 AppBar는 너무 독특해서 재사용 가능한 구성 요소라고 부를 수 없습니다. 래퍼/복합 구성 요소이며 이러한 경우 로컬 메서드를 사용하여 UI의 해당 부분을 빌드하지 않는 이유는 무엇입니까? 더 많은 작업을 수행했다면 래퍼/복합 구성 요소에 배치하는 것이 합리적일 것입니다.

Flutter에서 발견한 한 가지는 큰 빌드 방법이 성능에 좋지 않다는 것입니다.

성능에 대해 언급했으므로 애니메이션 루프가 빌드 메서드를 구동하도록 하면 부드러운 애니메이션에 대한 성능 문제가 발생합니다. 특히 빌드 메서드가 사용자 코드라는 점을 고려하면 빌드 메서드가 초당 60번 이상 호출되는 것을 원하지 않습니다(예를 들어, 무한히 걸리는 매우 긴 루프가 있을 수 있으며 애니메이션을 건너뛸 수 있음). Flutter 초보자이기 때문에 제가 틀렸을 수도 있습니다.

https://flutter.io/catalog/samples/basic-app-bar/ 의 AppBar는 너무 독특해서 재사용 가능한 구성 요소라고 부를 수 없습니다.

크기도 비교적 작으니 괜찮습니다.

성능과 관련하여 이것은 이 문제에 대해 다소 주제가 아니므로 논의하려면 새 문제를 제출하십시오(또는 이메일 flutter-dev 또는 스택 오버플로 게시, 원하는 대로).

https://github.com/Kotlin/anko/wiki/Anko-Layouts

이 문제가 묻히는 것을 보는 것은 미친 짓입니다. 제 생각에는 Flutter가 위젯을 구성하기 위해 JSX와 같은 구문을 구현하는 것은 성공하거나 중단될 것입니다.

나는 단순히 타겟 청중을 이해하지 못합니다. 많은 ios와 안드로이드 개발자들은 네이티브 반응으로 움직이고 있습니다. 시장 점유율을 수확할 완벽한 기회인 것 같습니다.

나는 관련된 사람들이 네이티브 반응을 해보고 우리가 무엇에 대해 이야기하는지 보도록 권장합니다.

나는 Flutter에서 JSX를 조금도 그리워하지 않습니다. 이것은 여기저기서 약간의 이익을 얻기 위해 프레임워크와 도구를 부풀릴 뿐입니다.

@birkir 이 문제에 대해 100% 동의합니다. Flutter에 완벽하게 맞는 JSX가 없기 때문에 Flutter는 낡고 녹슨 것처럼 보이며 1990년대 기술처럼 느껴집니다. 실제로 모든 사람이 어떤 방식으로든 JSX를 채택하고 있는 것 같습니다. 최신 버전은 인기 있는 Vue.js 프레임워크입니다.

+1

@zoechi JSX 에 대한 이전 경험은 무엇입니까? 실제로 사용했거나 방금 본 적이 있습니까? 나는 너희들이 JSX가 여기저기서 작은 이득을 줄 것이라고 말함으로써 JSX를 과소평가하고 있다고 생각한다. 사용자가 없으면 제품이 없는 것입니다.

@birkir 여기에서 JSX에 대한 많은 흥분을 보았지만 대부분 주관적인 더 나은 가독성을 제외하고 Flutter가 그러한 DSL을 사용함으로써 정확히 무엇을 얻을 수 있는지 설명하는 데 신경을 쓰지 않는 것 같습니다.

더 많은 기능은 일반적으로 프레임워크를 개선하는 대신 프레임워크를 약화시킵니다.
기능을 구현하면 실제로 사람들이 특정 응용 프로그램을 구현하는 데 방해가 되는 기능이 없는 다른 영역에서 누락된 리소스도 많이 소비합니다.

따라서 Flutter가 JSX와 같은 것을 얻는 것에 대해 흥분한다면 설득력 있는 주장을 작성하는 데 시간과 에너지를 투자해야 합니다.
다른 사람들도 가지고 있기 때문에 추가하는 것은 아마도 가장 약한 주장일 것입니다.

또한 JSX의 경우를 더욱 약화시키는 Flutter UI 코드 작성을 덜 장황하게 만들기 위해 Dart를 개선할 계획도 있습니다.

그렇다면 당신의 설득력 있는 주장은 무엇입니까?

정말로 !!! "아무도 Flutter가 정확히 무엇을 얻을 수 있는지 설명하려고 애쓰지 않는 것 같습니다... ㅋ ㅋ ㅋ".
이 스레드를 완전히 읽지 않았습니까? 주의 집중 시간이 JSX 지식보다 큽니까?

여러분은 NIH 증후군(여기서는 발명되지 않음)을 앓고 있습니다. "훌륭한 예술가는 베끼고 위대한 예술가는 훔친다" 평범한 예술가는 글쎄, 당신처럼 행동합니다.

JSX를 지원하는 것이 상대적으로 간단하고 새로운 고객(React Native 모바일 개발자)을 플랫폼으로 끌어들이는 데 엄청난 도움이 될 것이라는 사실만으로도 여러분이 보지 못하는 간단한 문제가 됩니다. 플랫폼에서는 굵게 표시되지 않습니다.

토론할 때 건설적인 어조를 유지할 수 있습니까?

다른 사람들이 주장이 약하기 때문에 기능을 추가합니다. 괜찮아.
플러터에 핫 리로딩이 있는 이유는 무엇인가요? 어디에서 왔습니까? 젠장.

우리가 어떻게 여러분에게 확고한 주장을 하지 못했습니까? 프로젝트 견인력과 개발자 유치 가 우리의 가장 큰 이유입니다.

두 번째 이유, 가독성 :

https://github.com/flutter/flutter/blob/master/examples/flutter_gallery/lib/demo/cupertino/cupertino_buttons_demo.dart 대 https://gist.github.com/birkir/e921158239c324ab95bb0b174383a562

세 번째 이유는 GUI 빌더 입니다. README의 첫 번째 줄을 인용하겠습니다.

개발자와 디자이너 가 iOS 및 Android용 최신 모바일 앱을 빌드하는 데 도움이 되는 새로운 모바일 앱 SDK입니다.

나는 Flutter가 베타에 도달하기 전에 Polymer와 같은 토끼굴로 내려가는 것을 보고 싶지 않습니다.

프로젝트 견인 및 개발자 유치

그 관계는 아직 불분명하다.

두 번째 이유, 가독성:

Dart 코드를 더 읽기 쉽게 만드는 것이 더 나은 목표로 보입니다.

세 번째 이유는 GUI 빌더입니다. README의 첫 번째 줄을 인용하겠습니다.

내가 기억하는 한 위에서 이미 언급한 것처럼 Dart 코드를 사용하면 이를 방지할 이유가 없습니다.

당신의 반대 주장은 정말 그 아이디어를 기각할 수 없습니까?

1. 관계는 꽤 명확합니다. 프로젝트가 대중화되는 것이 목표가 아니라면?
2. 엄청난! JSX 가독성에 가깝습니까? 그러한 것에 대한 현재 제안은 무엇입니까?
3. 할 수 있다고 밝혔습니다 . 현재 사용 가능한 GUI 빌더에 대한 JSX 지원을 적용하는 것은 훨씬 간단할 것입니다.

Flutter UI 코드를 덜 장황하게 작성하기 위해 Dart를 개선할 계획도 있습니다.

현재의 방식이 몇 가지 개선 사항을 사용할 수 있다는 인정을 보니 반갑습니다.
그러한 제안에 대한 세부 정보를 제공하십시오. 가장 좋은 방법은 피드백을 위해 React Native 커뮤니티와 상호 작용하는 것입니다.

여러 Dart 언어 기능 요청은 코드를 더 짧고 읽기 쉽게 만들 수 있습니다.

• Dart 2의 경우 new 및 const 옵션
• 모든 곳에서 명명된 인수를 허용하는 제안에 대한 메타 문제 - 이것은 child 인수가 있는 위젯이 명명된 인수를 건너뛰도록 허용할 수 있습니다.
  
  
  
  • 가변 인수 수 - children 인수가 있는 위젯(예: 행 및 열)이 이 명명된 인수 및 해당 목록 선언을 건너뛸 수 있습니다.
  
  

이러한 변경으로 코드는 다음과 같을 수 있습니다.

  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text('Cupertino Buttons')),
      body: Column(
        Padding(padding: EdgeInsets.all(16.0),
          Text(
            'iOS themed buttons are flat. They can have borders or backgrounds but '
            'only when necessary.'
          ),
        ),
        Expanded(
          Column(mainAxisAlignment: MainAxisAlignment.center,
            Text(_pressedCount > 0
                   ? 'Button pressed $_pressedCount time${_pressedCount == 1 ? "" : "s"}'
                   : ' '),
            Padding(padding: EdgeInsets.all(12.0)),
            Align(alignment: Alignment(0.0, -0.2),
              Row(mainAxisSize: MainAxisSize.min,
                CupertinoButton(onPressed: () { setState(() { _pressedCount += 1; }); },
                  Text('Cupertino Button'),
                ),
                CupertinoButton(onPressed: null,
                  Text('Disabled'),
                ),
              ),
            ),
            Padding(padding: EdgeInsets.all(12.0)),
            CupertinoButton(
              color: CupertinoColors.activeBlue,
              onPressed: () { setState(() { _pressedCount += 1; }); },
              Text('With Background'),
            ),
            Padding(padding: EdgeInsets.all(12.0)),
            CupertinoButton(
              color: CupertinoColors.activeBlue,
              onPressed: null,
              Text('Disabled'),
            )
          ),
        ),
      )
    );
  }

또한 IDE에 따라 선택적으로 괄호 끝에 합성 주석을 포함할 수 있으며 IDE에서 다음과 같은 것을 볼 수 있습니다.

  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text('Cupertino Buttons')),
      body: Column(
        Padding(padding: EdgeInsets.all(16.0),
          Text(
            'iOS themed buttons are flat. They can have borders or backgrounds but '
            'only when necessary.'
          ),
        ),
        Expanded(
          Column(mainAxisAlignment: MainAxisAlignment.center,
            Text(_pressedCount > 0
                   ? 'Button pressed $_pressedCount time${_pressedCount == 1 ? "" : "s"}'
                   : ' '), // Text
            Padding(padding: EdgeInsets.all(12.0)),
            Align(alignment: Alignment(0.0, -0.2),
              Row(mainAxisSize: MainAxisSize.min,
                CupertinoButton(onPressed: () { setState(() { _pressedCount += 1; }); },
                  Text('Cupertino Button'),
                ), // CupertinoButton
                CupertinoButton(onPressed: null,
                  Text('Disabled'),
                ), // CupertinoButton
              ), // Row
            ), // Align
            Padding(padding: EdgeInsets.all(12.0)),
            CupertinoButton(
              color: CupertinoColors.activeBlue,
              onPressed: () { setState(() { _pressedCount += 1; }); },
              Text('With Background'),
            ), // CupertinoButton
            Padding(padding: EdgeInsets.all(12.0)),
            CupertinoButton(
              color: CupertinoColors.activeBlue,
              onPressed: null,
              Text('Disabled'),
            ), // CupertinoButton
          ), // Column
        ), // Expanded
      ), // Column
    ); // Scafold
  }

이 대화가 뜨거워지고 있습니다. 저는 모든 사람들이 우리의 행동 강령을 읽을 것을 권장하고 싶습니다.
https://flutter.io/design-principles/#conflict - resolution
모든 사람들이 어떻게 정중하고 생산적으로 기여할 수 있는지 고려하는 동안 저는 이 대화를 며칠 동안 마치도록 하겠습니다.

UI 구축을 위한 구문은 모바일 개발 경험에서 매우 중요한 부분이라는 것을 우리 모두 알고 있습니다. 지금은 구문이 약간 장황합니다. 여백을 추가하기 위해 new 뭔가를 해야 합니다. margin: new EdgeInsets.symmetric(horizontal: 4.0) , 더 쉬운 방법이 있을 수 있다고 생각합니다.

Kotlin 팀이 Android 개발자를 위해 했던 것처럼 DSL을 구축할 수 있을까요? Android UI를 빌드하기 위한 DSL인 Anko 라고 합니다.

verticalLayout {
  padding = dip(30)
  editText {
    hint = "Name"
    textSize = 24f
  }
  button("Login") {
    textSize = 26f
  }
}

간결한 구문은 코드를 읽기 쉽고 유지 관리할 수 있도록 하고 빌드 작업을 즐겁게 만들 수 있습니다. 중요합니다. 결정을 내리기 전에 Flutter 팀에서 심각하게 평가해 주세요. 우리 모두는 Flutter가 앞으로 더 큰 성공을 거두기를 바랍니다.

Flutter에 XML과 유사한 구문을 도입하지 마세요.

1년 이상 Android Java로 프로그래밍한 다음 시도할 크로스 플랫폼 도구 모음을 찾기 시작했습니다.
React Native로 시작한 다음 React를 시도했습니다. JSX 문법은 자바스크립트도 아니고 html도 아니기 때문에 정말 마음에 들지 않았습니다.
Flutter를 시도했을 때 시작하기가 훨씬 더 쉽다는 것을 알았습니다(주로 Java 배경 지식 때문일 것입니다).

Flutter에 추가된 XML 구문을 보고 싶지 않은 몇 가지 이유가 있다고 생각합니다.

1. 배워야 할 또 다른 사항 - 대신 Futures를 배우는 데 쓸 수 있습니다.
2. 컨텍스트 스위칭 - XML과 코드 간의 컨텍스트 스위칭은 불필요한 인지 부하입니다.
3. 아침에는 Java로, 오후에는 Python으로 프로그래밍한 날이 있었습니다. React를 사용하면 하나의 코드베이스에서 Javascript, Babel, JSX, HTML, CSS 등을 이해해야 할 수도 있습니다.
4. Flutter에서 XML이 필요하지 않은 이유는 dart가 XML 속성을 대체하는 명명된 인수를 가지고 있기 때문입니다.
5. Dart는 노력 없이 코드를 정말 잘 들여쓰는 아주 멋진 dartfmt를 가지고 있습니다.

안드로이드와 비교

1. 어쨌든 프로그래밍 방식을 배워야 하는데, 다른 방식을 추가해야 하는 이유는 무엇입니까?
2. Android의 XML 레이아웃은 장치에 변경 사항을 표시하는 것이 더 빠르지만 Flutter에서 실행하는 것은 어쨌든 실질적으로 즉각적이므로 XML을 추가해도 이점이 제공되지 않습니다.
3. Android XML + 프로그래밍 방식의 조합은 XML 스니펫을 확장하고 프로그래밍 방식으로 XML 트리에 삽입하는 것과 같은 복잡성을 추가합니다.
4. Flutter에서 즉시 실행은 매우 빠르기 때문에 XML 모델이 표시되는 방식을 시각화하는 데 도움이 될 필요가 없습니다. 키를 누르고 변경 사항을 즉시 확인할 수 있습니다.
5. 프로그래밍 방식 레이아웃 문제의 오류는 XML의 레이아웃 문제와 다르므로 두 가지 집합을 이해해야 합니다.

한 단계 더 나아가 pubspec.yaml을 제거하고 pubspec.dart로 바꾸고 dart 코드로 구성하겠습니다.

개발자가 페이지를 시각적으로 레이아웃하는 것이 어렵다고 불평하는 경우 - 테마를 설정하고 페이지를 드래그 앤 드롭으로 시각적으로 디자인할 수 있는 레이아웃 디자이너를 만드는 것이 좋습니다. 그런 다음 편집할 의도가 없는 Flutter 코드를 생성하지만 앱을 구성하는 데 사용할 수 있는 클래스를 생성합니다.

Android XML과 같은 양방향 편집(XML/레이아웃)일 필요는 없지만 나중에 사용할 수 있도록 레이아웃을 저장하면 됩니다. 변경해야 하는 경우 코드를 다시 생성할 수 있고 (바라건대) 일부 인수만 변경할 수 있습니다.

나는 이 대화가 오래되었다는 것을 알고 있고 꽤 뜨거워지고 있다는 것을 알고 있습니다. 하지만 여기서 일어나고 있다고 생각하는 것에 대해 몇 줄을 떨어뜨리고 싶습니다.

플러터는 새로운 기능입니다. 완전히 새로운 방식으로 작업을 수행합니다. 예, 반응 패러다임에서 차용했습니다. 그러나 동일한 단계를 따라야 하는 것은 아닙니다. Flutter의 팀 목표는 개발자를 반응 네이티브에서 Flutter로 끌어들이는 것이 아니라 개발자가 관심을 가질 수 있는 새로운 것을 구축하는 것뿐이라고 생각합니다. Google은 이를 세계와 공유하기 전에 내부적으로 사용하며 생산성을 높였습니다. 그것. @Hixie 와 의견을 공유하여 UI를 빌드하는 데 JSX와 다르지 않습니다. 예, 오른쪽 순수 다트에 대해 조금 더 장황합니다. 그러나 실제로 코드 디버깅을 훨씬 쉽게 만듭니다.

마크업 언어나 JSX 또는 기술 위에 있는 모든 것에 반대하는 이유는 플랫폼에서 훨씬 더 많은 작업이 필요하기 때문입니다. UI용 마크업 언어를 작성하는 것은 행복할 수 있지만 플랫폼에서 작업하는 많은 개발자가 당신을 위해 울고 머리카락을 뽑게 될 것입니다. 또 다른 관점은 JSX가 Javascript 커뮤니티에 적합하다는 것입니다. JSX의 주요 목표는 항상 그렇듯이 개발자를 위해 일을 더 쉽게 만들고 절충점에 대해 걱정하지 않는 것입니다. 오해하지 마세요. HTML은 어쨌든 마크업이기 때문에 웹용 React(JSX)는 천국과도 일치합니다. 그러나 React Native의 경우 저장소의 모든 코드를 살펴보고 제대로 작동하도록 해야 했습니다. Flutter에 JSX를 추가하려면 많은 작업이 필요하고 새로운 기능을 추가할 때 2가지를 고려해야 합니다. 그리고 다시 자식 매개변수와 const 및 새 키워드를 제거할 수 있습니까? 나는 코드에서 실제로 일어나는 일을 아는 것을 선호하고 모든 일이 오버헤드를 추가하는 마법 같은 구문을 사용하는 것보다 무슨 일이 일어나고 있는지 제어할 수 있습니다.

그게 제 의견입니다. 새로운 거대한 토론을 시작하고 싶지 않습니다. JSX가 반응/자바스크립트 커뮤니티에서 효과가 있었기 때문에 훌륭하다는 사실을 언급하자면, Dart/flutter의 경우 React Native에서 개발자를 끌어들이기 위해 JSX를 추가하는 것이 약간 과하다고 생각합니다.

와우, 블로그 게시물을 작성할 수 있었습니다 xD

@록볼

배워야 할 또 다른 사항 - 대신 Futures를 배우는 데 쓸 수 있습니다.

배울 점은 현재의 재귀 객체 생성 괴물을 일상적인 React Native 개발자에게 더 간단하고 친숙하게 만들어 주므로 사람들이 그것을 배우는 것을 선호할 것입니다.

컨텍스트 스위칭 - XML과 코드 간의 컨텍스트 스위칭은 불필요한 인지 부하입니다.

문제가 아니라 컨텍스트 스위치가 없으며 프로그래밍 UI/UX를 더 깔끔하게 만드는 환경의 일부일 뿐입니다.

그런 다음 편집할 의도가 없는 Flutter 코드를 생성합니다.

왜 안 돼? 별로 유용하지 않습니다.

@franzsilva

나는 개발자를 반응 네이티브에서 플러터로 끌어들이는 것이 플러터의 팀 목표라고 생각하지 않습니다.

정말로 !!! React Native가 지배적이며 크로스 플랫폼 도구를 사용하는 모바일 개발자의 총 수가 제한되어 있다는 점을 감안할 때 Flutter가 React Native 사람들을 끌어들이지 않고도 홈런 히트가 될 수 있다고 생각하십니까?

예, 오른쪽 순수 다트에 대해 조금 더 장황합니다. 그러나 실제로 코드 디버깅을 훨씬 쉽게 만듭니다.

그것은 올바른 진술이 아닙니다. 자바스크립트 코드일 뿐인 JSX 코드를 디버깅하는 것은 더 쉽거나 어려운 것이 아니라 동일합니다.

마크업 언어나 JSX 또는 기술 위에 있는 모든 것에 반대하는 이유는 플랫폼에서 훨씬 더 많은 작업이 필요하기 때문입니다.

플랫폼에 얼마나 많은 작업이 배치되었는지 누가 신경 쓰나요? 개발자는 코드 가독성과 생산성을 향상시키는 최신 기술을 원합니다. 새로운 것이 더 나은 대안을 제공할 때 오래된 기술을 사용하고 싶어하는 개발자는 없습니다.

나는 코드에서 실제로 일어나는 일을 아는 것을 선호하고 모든 일이 오버헤드를 추가하는 마법 같은 구문을 사용하는 것보다 무슨 일이 일어나고 있는지 제어할 수 있습니다.

이것은 말도 안되는 소리입니다. JSX에서 무슨 일이 일어나는지 정확히 알고 있습니다. 거의 1:1로 변환하지만 많은 이점을 제공하는 아주 작은 레이어입니다. 나에게 묻는다면 무시할 수 있는 컴파일 시간 오버헤드.

JSX가 반응/자바스크립트 커뮤니티에서 효과가 있었기 때문에 훌륭하다는 사실을 언급하자면, Dart/flutter의 경우 React Native에서 개발자를 끌어들이기 위해 JSX를 추가하는 것이 약간 과하다고 생각합니다.

JSX는 Dart/Flutter에서도 잘 작동해야 합니다. 그것은 어떤 의미에서 과잉이 아닙니다. JSX가 Dart/Flutter에서 작동하지 않는 이유가 있습니까? 내가 그것을 코딩하고 출시한다면 왜 Dart/Flutter 개발에 적합하지 않을까요?

@xinthink 의 구체적인 예를 들어 보겠습니다.

지금은 구문이 약간 장황합니다. 여백을 추가하기 위해 new 뭔가를 해야 합니다. margin: new EdgeInsets.symmetric(horizontal: 4.0) , 더 쉬운 방법이 있을 수 있다고 생각합니다.

왼쪽과 오른쪽에 여백을 추가하고 싶다면 어떻게 표현하시겠습니까? 특히 간단한 예를 들어 다양한 구문에서 어떻게 보이는지 살펴보겠습니다.

  // Flutter as written today
  return new Container(
    margin: new EdgeInsets.symmetric(horizontal: 4.0),
    decoration: new ShapeDecoration(shape: new CircleBorder(), color: Colors.blue[100]),
    child: new AnimatedCrossFade(
      duration: const Duration(seconds: 3),
      firstChild: const FlutterLogo(style: FlutterLogoStyle.horizontal, size: 100.0),
      secondChild: const FlutterLogo(style: FlutterLogoStyle.stacked, size: 100.0),
      crossFadeState: _showHorizontal ? CrossFadeState.showFirst : CrossFadeState.showSecond,
    ),
  );

  // Flutter as written later this year once we remove "new" and "const" keywords
  return Container(
    margin: EdgeInsets.symmetric(horizontal: 4.0),
    decoration: ShapeDecoration(shape: CircleBorder(), color: Colors.blue[100]),
    child: AnimatedCrossFade(
      duration: Duration(seconds: 3),
      firstChild: FlutterLogo(style: FlutterLogoStyle.horizontal, size: 100.0),
      secondChild: FlutterLogo(style: FlutterLogoStyle.stacked, size: 100.0),
      crossFadeState: _showHorizontal ? CrossFadeState.showFirst : CrossFadeState.showSecond,
    ),
  );

이러한 _정확한_ 의미를 표현하는 방법을 추천하시겠습니까?

  // Remove "new" and "const", infer the class for enum values, allow int literals for doubles
  return Container(
    margin: EdgeInsets.symmetric(horizontal: 4),
    decoration: ShapeDecoration(shape: CircleBorder(), color: Colors.blue[100]),
    child: AnimatedCrossFade(
      duration: Duration(seconds: 3),
      firstChild: FlutterLogo(style: horizontal, size: 100),
      secondChild: FlutterLogo(style: stacked, size: 100),
      crossFadeState: _showHorizontal ? showFirst : showSecond,
    ),
  );

Babel.js에는 JSX를 입력하고 일반 자바스크립트로 변환할 수 있는 깔끔한 작은 웹사이트가 있습니다.
https://babeljs.io/repl/# ?babili=false&evaluate=true&lineWrap=false&presets=es2015%2Creact%2Cstage-0&code=function%20hello()%20%7B%0A%20%20return%20%3Cdiv%3EHello% 20세계!%3C%2Fdiv%3E%3B%0A%7D

DSX to Dart에 대해 동등한 작업을 수행하겠습니다. 개념 증명일 뿐이니 시간이 얼마나 걸리는지 봅시다...

다음은 Airbnb의 스타일 가이드 를 사용하고 모든 하위 요소가 child 속성에 자동으로 매핑될 수 있다고 가정하는 "DSX"에서 @Hixie의 최신 예입니다.

return (
  <Container
    margin={EdgeInsets.symmetric(horizontal: 4)}
    decoration={ShapeDecoration(shape: CircleBorder(), color: Colors.blue[100])}
  >
    <AnimatedCrossFade
        duration={Duration(seconds: 3)}
        crossFadeState={_showHorizontal ? showFirst : showSecond}
    >
      <FlutterLogo style={horizontal} size={100} />
      <FlutterLogo style={stacked} size={100} />
    </AnimatedCrossFade>
  </Container>
);

가독성을 높이려는 의도라면 미래의 Dart가 삽시간에 승리할 것이라고 생각합니다.

무엇이 태그로 바뀔 수 있는지(아마도 Widget 만) 또는 얼마나 많은 하위 요소가 필요/허용되는지 문서를 확인해야 합니다.

목표가 JavaScript에서 HTML을 출력하는 것이라면 JSX는 중간 지점으로 많은 의미가 있습니다. 하루가 끝날 때 태그를 원할 때 React.createElement('div', null, 'foo') 는 <div>foo</div> 보다 훨씬 나쁩니다.

목표가 Dart에서 Dart 개체 트리를 출력하는 것이고 멋지게 형식이 지정된 Dart 생성자 트리를 완벽하게(아마도 더 많이) 읽을 수 있다면 XML을 통해 우회하는 것이 중요하다고 생각하지 않습니다. 그리고 Android에서 가져온 XML이 누락되지 않았습니다.

그것은 XML을 사용하여 가능하게 하는 것입니다... 보세요. 말만 하고 5개월이 지났습니다. 이제 그것에 대해 뭔가를 하고 있으므로 시간을 주십시오.

이 스레드를 찾았습니다. 양쪽에서 모두 흥미롭습니다. Flutter에 관심이 있는 React 개발자로서 언급하지 않은 몇 가지 다른 주장이 있습니다.

1. 태그 선언을 닫으면 자식 대 속성에 대한 이해가 높아집니다. UI는 불행히도 깊이 중첩될 수 있으며 명확한 태그 대 알 수 없음 )이 있으면 하위 항목을 명확하게 하고 구문 분석하는 데 도움이 됩니다. 또한 구성 요소 사이에서 코드를 이동할 수 있고 무언가가 제자리에 없을 때 매우 선언적으로 볼 수 있습니다(예를 들어 태그 앞에 닫는 태그). 이것은 여러 중첩된 경우 더 까다롭습니다.

2. 생성자 내부의 여러 중첩 구성 요소를 보는 것에 대한 나의 초기 직감 반응은 "콜백 지옥" 에 대한 플래시백을 제공합니다. 점점 나아지기 시작하는 JS의 매우 고통스러운 시대였습니다. 다시 돌아가면 한 걸음 뒤로 물러난 것 같은 느낌이 듭니다.

3. #2와 관련하여 불행한 사실은 사람들이 전환하도록(또는 적어도 시도하도록) 설득해야 한다는 것입니다. 많은 사람들이 React/React Native를 사용하고 있으며 HTML/JS를 더 많이 사용하고 있습니다. React의 문제점 중 일부를 구체적으로 대상으로 하는 간단하고 대부분 구문적으로 친숙한 튜토리얼/가이드를 만드는 것은 약간 피곤한 사람들에게 매우 매력적일 수 있습니다.

웹 개발자 커뮤니티에서 React가 인기를 얻은 주된 이유 중 하나는 JSX의 지원이었습니다.

그런 멋진 기능 요청에 대해 "하향 투표"를 보는 것은 정말 실망스럽습니다. 가독성이 향상되고 채택이 빨라집니다.

이것이 Open JavaScript와 Dart의 주요 차이점이라고 생각합니다. JavaScript는 진정한 오픈 소스인 반면 Dart에 대한 요청은 이와 같은 대화에 들어가 궁극적으로 반대 투표로 의욕을 잃게 됩니다.

새로운 아이디어를 위한 더 많은 공간을 만드십시오!

@jayjun 멋지네요 ! 어딘가에서 시도 할 수 있습니까?

@sanketsahusoft 곧 내 버전을 사용해 볼 수 있을 테니 걱정하지 마세요. @jayjun보다 훨씬 낫습니다.

빠른 업데이트: 2주 전 UI가 훌륭하게 작동했습니다. 지난 주말에는 파서가 완전히 작동하고 트랜스파일러의 절반이 작동했습니다. 이번 주말은 슈퍼볼만 피하면 끝내고 싶어요 ;)

나는 피부가 두껍고 고집이 센 노새라 이런 반대표조차 눈치채지 못했는데 지적해줘서 고맙다.

카를로스.

닫는 태그를 추적하지 못하는 문제에 도움이 될까요?
아이디어: 자동 생성된 닫는 태그

다음은 @Hixie 의 예에 대해 제안된 몇 가지 마크업 구문입니다.

<Container margin=<EdgeInsets.symmetric horizontal=4 />
           decoration=<ShapeDecoration shape=<CircleBorder> color={{ Colors.blue[100] }} />>
    <AnimatedCrossFade duration=<Duration seconds=3 />
                       crossFadeState={{ _showHorizontal ? showFirst : showSecond }}>
      <FlutterLogo style=horizontal size=100 />
      <FlutterLogo style=stacked size=100 />
    </AnimatedCrossFade>
</Container>

@abarth , 당신이 한 흥미로운 일은 표현식이 다른 태그일 때 표현식의 모양을 단순화하는 세 번째 속성 가능성을 추가한 것입니다.
JSX에는 다음이 있습니다.
1 - <tag attrib=""/> 또는 <tag attrib=''/>
2 - <tag attrib={}/>
당신은 다른 하나를 제안했습니다:
3 - <tag attrib=<anotherTag.../>/>
JSX에서는 다음과 같이 작성해야 합니다.
<tag attrib={<anotherTag.../>}/>

@cbazza 예, 세 번째 경우는 Flutter에서 매우 일반적이므로 추가 { 중첩을 건너뛰는 것이 좋습니다.

@abarth 아 근데 css같은 스타일을 사용해서 그런거 대부분 불필요하게 만들고 있어요!!! 트랜스파일러는 이러한 CSS와 유사한 스타일을 적절한 Flutter 호출로 확장합니다. 이제 태그 구조가 훨씬 깨끗해지고 InVision, Figma, Atomic 등과 같은 디자이너 도구에서 스타일을 쉽게 가져올 수 있습니다.

@cbazza Cool, 저는 FutureBuilder 와 같은 클로저가 있는 많은 위젯을 사용합니다. 트랜스파일러가 다음과 같은 것을 생성할 수 있기를 바랍니다.

return new FutureBuilder(
  future: Firestore.instance
      .collection('stuff')
      .document(id)
      .get(),
  builder: (context, snapshot) {
    if (!snapshot.hasData) {
      switch (snapshot.connectionState) {
        case ConnectionState.waiting:
          return const Text('Loading...');
        default:
          return new Text('${id} not found');
      }
    }

    return new Text(snapshot.data['name']);
  },
);

@jayjun , 네, 문제가 되지 않습니다. 트랜스파일러는 간단한 XML 프로세서이며 식({} 내부의 모든 것)을 구문 분석할 때 텍스트 덩어리가 되어 그대로 기록합니다.

@xinthink

Kotlin 팀이 Android 개발자를 위해 했던 것처럼 DSL을 구축할 수 있을까요?

많은 사람들이 Flutter와 함께 Kotlin을 사용하고 싶어하는 것 같습니다. 솔직히 이해가 되지 않습니다. 왜 개발자들은 Dart에서 바퀴를 재발명하기로 결정했을까요?

내 겸손한 의견으로는 Flutter에는 JSX가 필요하지 않습니다. Flutter는 Dart 대신 Kotlin을 선택했어야 했습니다. Kotlin을 사용하면 즉시 사용할 수 있는 아름다운 구문으로 복잡한 UI 로직을 작성할 수 있으며, 대규모 커뮤니티, 프로덕션 준비 도구, Android 개발에서 전투 테스트를 거쳤습니다...

그냥.

Kotlin은 훌륭합니다. 저는 팬 이지만 iOS에서 실행되지 않습니다..... 실제로는 실행되지만 아직 출시되지 않았습니다(현재 사전 출시 단계).
UI/UX 개발의 경우 여전히 Anko DSL 대신 JSX를 선호합니다. 명령형 코드에서 선언적 마크업을 시각적으로 분리할 수 있고 구성 요소를 매우 쉽게 혼합 및 일치시킬 수 있다는 사실이 마음에 듭니다.

Dart, Kotlin 및 Swift는 모두 유사점이 있습니다.
https://sethladd.github.io/swift-is-like-kotlin-and-kinda-like-dart/

나는 그것을 좋아한다 :

1. Dart는 Java 출신이라면 더 친숙합니다.
2. Dart 기술을 사용하여 웹 페이지를 구축할 수 있습니다. 이는 앱을 만들 때 유용하며 웹에서 기능을 구축하고 WebView에 표시할 수 있습니다. Google 색인이 필요합니다).
3. Dart는 나중에 언어에 추가하기가 쉽지 않다고 생각하는 자바스크립트로 컴파일하기 위해 처음부터 만들어졌습니다.

이것이 기본적으로 내가 Kotlin / Swift / React보다 Dart를 선택한 이유입니다.

_Google의 새로운 Fuchsia OS에서 Dart와 Swift를 지원하기로 한 결정이 저에게는 혼란스럽긴 하지만._

Java 출신이라면 Dart가 더 친숙할지 모르겠습니다. 저는 Java에서 왔으며 Kotlin 또는 Swift에 문제가 없습니다. 기본적으로 유형 선언은 반대이며 Pascal 및 ActionScript에서 사용된 것처럼 실제로 새로운 것은 없습니다.

예, Dart로 웹 페이지를 구축할 수 있지만 주요 내용은 그렇지 않습니다. 웹에서 잘 작동하는 유일한 다른 언어는 가장 인기 있는 상위 3개 웹 프레임워크와 잘 통합되기 때문에 TypeScript입니다.

웹에서 React에 사용할 수 있는 다양한 구문을 살펴보세요.
https://github.com/Workiva/over_react#fluent -style-component-consumption
두 Dart 버전 모두 JSX에 대항할 기회가 없습니다!!!

TypeScript는 Javascript로 컴파일하도록 설계되었으며 Dart보다 낫습니다. JSX도 지원합니다.
다트가 사방에서 압박되고 있습니다. Swift는 추진력이 있으므로 아기와 함께 Fuchsia OS에서 지원하는 것이 좋습니다.

프로토타입까지 얼마나 걸립니까? 나는 그것을 사용하고 싶습니다!

나는 한동안 React를 사용했고 JSX는 생산성을 10배 증가시켰습니다. 이것은 논란의 여지가 없는 문제가 아닙니다. 다른 팀은 이것이 더 나을 것이라고 올바르게 결정했는데 Flutter가 아닌 이유는 무엇입니까? (수사적: 스레드를 읽습니다... (페이스팜))

이번 주말에 작업을 하고 있지만 새로운 아이디어로 범위를 계속 늘리고 있으므로 이번 주말에 무언가를 얻을 수 있기를 바랍니다.

내가 실험하고 있는 몇 가지 흥미로운 것들:
1) 자식 태그에 xml 네임스페이스를 사용하여 부모에 올바른 Dart 이름 인수와 함께 삽입되도록 합니다.
2) 속성과 같은 스타일을 더 잘 구성하기 위해 스프레드 연산자를 사용하여 맵의 xml 외부에서 정의/그룹화한 다음 일반적인 React 항목과 같은 태그에 가져와서 퍼뜨릴 수 있습니다.
3) CSS에서 플러터 스타일을 생성하는 styleCSS 속성.

(1) & (2)는 일반적이므로 모든 Dart Flutter 코드에서 작동합니다.
(3)은 Flutter 위젯(컨테이너, 텍스트 등)별로 특화되어 있으며 지금은 이 2개만 하고 있습니다.

@yuriy-manifold JS에서 효과가 있었다고 해서 그것이 Dart에 좋은 아이디어라는 의미는 아닙니다.
위의 토론을 읽었다면 사실 그것이 논란의 여지 가 있음을 알 수 있습니다.
2개 언어가 1개 언어보다 나은 이유를 모르겠습니다.

JS에서 효과가 있었다고 해서 그것이 Dart에 좋은 아이디어라는 의미는 아닙니다.

JSX는 언어에 관계없이 반응형 프레임워크에서 UI/UX 개발을 위한 놀라운 아이디어입니다. 여유 시간이 더 있었다면 로고용 JSX인 LSX를 내놓았을 것입니다.)

2개 언어가 1개 언어보다 나은 이유를 모르겠습니다.

Objective-C 및 Swift로 iOS를 프로그래밍할 수 있습니다(2개 언어)
Java 및 Kotlin으로 Android 프로그래밍 가능(2개 언어)
...

나는 아직 JSX에 찬성하는 주장을 보지 못했습니다.
위의 논의에는 "더 낫다", "생산성 향상" 또는 이와 유사한 주장만 포함되어 있지만 순수 Dart 코드보다 실제로 왜 또는 어떻게 더 좋을지에 대한 논쟁은 없습니다.
순수한 Dart 코드는 더욱 더.

@cbazza

Objective-C 및 Swift로 iOS를 프로그래밍할 수 있습니다(2개 언어)
Java 및 Kotlin으로 Android 프로그래밍 가능(2개 언어)

JSX 토론과 어떤 관련이 있습니까? 그것이 어떻게 장점이라고 할 수 있습니까?
Objective-C의 후속 제품이기 때문에 iOS에서 Swift를 사용할 수 있습니다.
Java에 대한 매끄러운 개선으로 간주되기 때문에 Android에서 Kotlin을 사용할 수 있습니다.
JSX가 Dart를 대체해야 한다고 주장하는 것처럼 들립니다. 그것은 나에게 큰 의미가 없습니다.

@zoechi

JSX 토론과 어떤 관련이 있습니까? 그것이 어떻게 장점이라고 할 수 있습니까?
Objective-C의 후속 제품이기 때문에 iOS에서 Swift를 사용할 수 있습니다.
Java에 대한 매끄러운 개선으로 간주되기 때문에 Android에서 Kotlin을 사용할 수 있습니다.
JSX가 Dart를 대체해야 한다고 주장하는 것처럼 들립니다. 그것은 나에게 큰 의미가 없습니다.

당신은 실제로 그것을 말했지만(JSX는 현재 방식에 비해 매끄러운 개선입니다) 잘못된 결론에 도달했습니다(JSX는 Dart를 대체함).

@cbazza 그 이상입니다.

일반 Dart에 비해 실제 이점은 무엇입니까?

"JSX는 매끄러운 개선입니다"는 어떤 식으로든 설득력이 없고 논쟁거리가 아닙니다.
(다시) 뒷받침할 근거가 없는 개인적인 의견일 뿐입니다.
위의 다른 pro-JSX 인수와 유사합니다.

당신이 좋은 논거를 제공할 의사가 없다면 아무도 당신의 제안을 고려할 것이라고 기대할 수 없습니다.

JSX와 같은 것을 Dart에 추가하면 Flutter 도구와 IDE에서 엄청난 양의 작업과 복잡성이 발생합니다. 다른 사람들이 검토할 수 있도록 적절한 논거를 제공해야 합니다.

@zoechi 는 '좋은' 인수를 요구하는 깨진 레코드처럼 들립니다. 이전에 많은 것이 주어졌지만 당신은 그것을 얻지 못했습니다. '각자에게' 맞습니다.

JSX와 같은 것을 Dart에 추가하면 Flutter 도구와 IDE에서 엄청난 양의 작업과 복잡성이 발생합니다. 다른 사람들이 검토할 수 있도록 적절한 논거를 제공해야 합니다.

아니요, 제 작업은 거의 준비가 되었고 주말에만 작업했기 때문에 시간이 거의 걸리지 않았습니다.

다시 말하지만, DSX는 현재 방식을 변경하지 않고 다른 사람들(React 개발자)이 즉시 친숙해질 대안을 제공하기 때문에 사람들이 사용 여부를 선택할 수 있는 매끄러운 개선 사항입니다.

@cbazza

많이 주어졌다

설마. 사실일 수도 있고 아닐 수도 있는 일반적인 주장일 뿐입니다.
다른 사람들이 확인할 수 있는 추가 세부정보는 제공되지 않았습니다.

아니요, 내 작업은 거의 준비되었습니다.

엄청난. 그러면 Flutter 팀이 아무 것도 할 필요가 없으며 문제를 종료할 수 있습니다.
여기에는 Flutter가 지원하는 모든 IDE의 자동 완성 및 구문 검사 지원이 포함됩니까?

엄청난. 그러면 Flutter 팀이 아무 것도 할 필요가 없으며 문제를 종료할 수 있습니다.

;)

여기에는 Flutter가 지원하는 모든 IDE의 자동 완성 및 구문 검사 지원이 포함됩니까?

대부분의 IDE는 이미 XML과 JSX를 지원하므로 내가 사소한 추가 사항을 추가하는 것이 어렵지 않을 것입니다.

JSX 구문이 Angular Dart에서 더 높이 평가될 수 있는지 궁금합니다. "더 낫다"는 것보다 익숙한 상황에 더 가까운 것 같습니다. JSX 구문은 웹 개발자에게 더 자연스럽게 느껴질 것입니다.

하루 동안 다른 코드 강조 표시 색상을 사용하는 것만으로도 프로그래밍이 어색하게 느껴진다는 것을 알고 있습니다.

https://blog.dantup.com/2014/08/you-have-ruined-html/

예, Angular 사람들은 JSX에 매우 익숙할 것이지만 React Native 개발자도 마찬가지이며 이것은 모바일 개발을 위한 것입니다. JSX는 현재 Flutter 개발자가 사용하지 않을 것이지만 이 두 번째 대안은 새로운 개발자를 Flutter로 끌어들일 것입니다.

위의 기사는 너무 틀렸습니다. JSX가 없는 React는 기본적으로 존재하지 않으며 모든 반응형 웹 프레임워크는 DSL에서 마크업과 프로그래밍을 혼합할 수 있습니다.

시간이 왔다...
온라인 DSX 변환기를 발표하게 되어 매우 기쁩니다.
https://spark-heroku-dsx.herokuapp.com/index.html

트랜스 파일러 cbazza로 작업하기 좋습니다.
내가 말하고 싶은 한 가지는 JSX를 따라하기가 더 쉽다는 것입니다. 닫는 태그입니다. 내가 전에 언급한 아이디어 :
아이디어: 자동 생성된 닫는 태그

첫 번째 예에서 다음과 같은 플러터 코드를 제공합니다(미래의 Dart에서 선택적 new 제거).

Material(
  child: Column(
    children: <Widget>[
      MyAppBar(
        title: Text(
          'Example title',
          style: Theme.of(context).primaryTextTheme.title,
        )-Text,
      )-MyAppBar,
      Expanded(
        child: Center(
          child: Text(
            'Hello, world!',
          )-Text,
        )-Center,
      )-Expanded,
    ],
  )-Column,
)-Material;

@cbazza 커뮤니티와 UI를 그런 식으로 구축하려는 사람들을 위한 작업에 감사드립니다. 하지만 Flutter에서 그런 것을 강제로 사용하지 않기를 진심으로 바랍니다 :-(((

Flutter를 처음 접했지만 React에 꽤 익숙한 저에게 몇 가지 눈에 띄는 점이 있었습니다.

• 상태 관리 모델은 거의 동일합니다.
• 위젯/컴포넌트 가상 렌더 트리는 거의 동일합니다.
• 상태 및 구성 요소 모델을 알면 기본적으로 일부 Dart 사양 및 플랫폼 API를 제외하고 이제 앱을 작성할 준비가 된 것 같지만...
• 스타일링 언어는 걸림돌입니다. https://flutter.io/web-analogs/ 를 참조하고 있지만 작업을 수행하기 위해 어떤 가져오기가 필요한지(EdgeInset? Color?) 또는 언제 클래스 인스턴스 대신 프리미티브를 사용해야 하는지 파악하는 것이 쉽지 않습니다.
• @cbazza 의 DSX 변환기에서 가져온 CSS 파서는 Flutter 모델에서 동등한 레이아웃을 찾는 데 정말 유용합니다.

JSX에 관하여:

• Flutter 패턴을 지원하기 위해 새로운 JSX 구문을 발명할 필요가 없다고 생각합니다. 이 스레드의 일부 구문 문제는 고차 구성 요소 (구성 요소 클래스를 빌드하는 함수) 및 렌더링 소품 (함수를 인수로 사용하는 구성 요소, 함수는 요소를 반환)과 같은 새로운 React 패턴을 사용하여 해결할 수 있습니다. 예를 들어 "하위 슬롯"이라는 이름은 JSX에서 다음과 같이 번역될 수 있습니다.

<Item
  right={() => new Text("Right")} {/* a named slot */}
  left={() => new Text("Left")}> {/* another named slot */}
  <ChildOne /> {/* generic children prop with 2 children */}
  <ChildTwo>
    <NestedChild />
  </ChildTwo>
</Item>

• 내가 본 JSX에 대한 최고의 논쟁은 Dart가 인수를 명명했다는 것입니다.
• 요소에 자식이 여러 개 있는지 아니면 하나의 자식이 있는지 아는 것이 왜 중요한가요? 아마도 "fragment" 구조 가 해당 API를 명확하게 할 수 있습니다.

Angular, React 등에 대한 약간의 경험이 있는 Flutter의 초보자인 저는 여전히 일반적인 Dart 방식과 Dart 2.0의 기타 방식이 이 DSX보다 낫다고 생각합니다. 일부 XML 및 CSS-ish 매개변수보다 더 합리적입니다. 🤷‍♂️

@cbazza 두 번째 데모 예제에는 dart의 391개(둘 다 공백 없음)와 비교하여 466개의 문자가 있습니다. 제가 보기에는 시각적으로 부풀어 오르는 것 같습니다. 나는 그것이 의미론이라는 것을 배워야 할 것입니다. 정상적인 Dart 코드에서는 그럴 필요가 없습니다. 그리고 범용 프로그래밍 패러다임(if, forEach 등)을 사용하는 방법을 모르겠습니다.

선택의 여지가 있다면 현재 모델을 고수할 것입니다.

모두가 두 구문을 비교하는 데 있어 주관적인 의견을 제시하고 있지만 한 가지 사실에 동의해야 합니다. 이는 매우 논란의 여지가 있는 기능입니다. 사랑과 미움이 있지만 대부분의 의견은 일반 Dart보다 JSX의 유용성에 대해 다릅니다.

어쨌든 Flutter 팀에 1.0 릴리스 이전에 이 기능을 지원하도록 약속하는 것은 완전히 불합리하다고 생각합니다. UI를 구축하는 현재 방법이 모든 사람에게 좋지 않은 것처럼 보일 수 있지만 작동합니다(일부 의견에서는 훌륭하게 작동합니다).

사람들이 지금 JSX와 같은 구문을 원한다면 커뮤니티 주도의 노력이 필요한 것 같습니다. 그리고 Flutter 팀이 1.0 이후 릴리스에서 이를 고려할 때 사례를 만드는 데 도움이 될 것입니다.

개인적으로 저는 다음 주장에 강력하게 동의합니다. JSX가 React(이미 마크업 언어를 사용하여 UI를 빌드하고 있는 곳)에서 작동하기 때문에 Flutter에서 자동으로 작동하기 때문이 아닙니다.

@tehfailsafe

좋은 소식은 이것이 Flutter 팀(이 스레드를 기반으로 하지 않을 가능성이 높음)에 의해 채택되었지만 아무도 강제로 사용하지 않는다는 것입니다. 옵션입니다. 왜 일부 사람들은 당신이 좋아하지 않는 구문으로 코드를 작성하는 것을 좋아할 정도로 감정적으로 부담을 느끼는지 이해가 되지 않습니다...

나는 다른 사람들이 무엇을 좋아하든 좋아하지 않든 상관하지 않는다. 하지만 저는 응용 프로그램을 진행하는 데 도움이 되는 기능에 관심이 있습니다. 리소스가 제한되어 있으며 적절한 비디오/스트림 플레이어, 기본 하위 보기 및 일부 벡터 그래픽 형식을 사용하는 것이 좋습니다.

예를 들어, 현재 React 및 React Native에서 JSX 없이 전체 애플리케이션을 작성할 수 있으며 이는 단지 옵션일 뿐입니다. JSX가 없는 React는 다음과 같습니다.
[...]
JSX 버전보다 훨씬 더 지저분하고 거의 아무도 사용하지 않습니다. 이것이 아마도 React에서 온 우리 중 일부가 이 스타일을 다시 수행하지 않아도 되는 가능성을 높이 평가하는 이유일 것입니다.

웹이 그런 시스템을 위해 설계되지 않았기 때문입니다. HTML과 같은 정적 마크업 언어가 있고 이를 "동적화"하려면 그 위에서 작동해야 하는 시스템을 발명해야 합니다. 결국 기본 플랫폼에 의해 제약을 받는 일부 구성으로 끝납니다.
(참조: https://gbracha.blogspot.de/2014/09/a-domain-of-shadows.html)

반면 Flutter에는 마크업 언어가 없습니다. 덜 역동적이고 덜 표현적인 것에 자원을 투자할 이유를 아직 보지 못했습니다.

이에 동의하지 않는 사람들이 JSX가 있거나 없는 React를 사용했는지 알고 싶습니다. 나는 모든 사람들이 그것을 시도하도록 권장하므로 이 토론은 덜 이론적입니다. 초기의 얕은 학습 곡선 후에는 매우 자연스러워집니다(그리고 닫기 태그를 사용하면 더 쉽게 읽을 수 있기 때문에 문자 수가 전부는 아닙니다). 장기적으로 생산성을 높이는 Flutter와 같이 새로운 것을 배우는 것과 다르지 않습니다. 그리고 나는 그것이 모든 사람을 위한 것이 아니라는 데 동의합니다. 그렇기 때문에 선택 사항이 될 것입니다.
우리는 서로의 최대 이익을 염두에 두는 것이 중요하다고 생각합니다. 즉, 물건을 더 쉽게 만들 수 있습니다. 이 트랜스파일러가 도움이 될 것이라고 생각하고, 공식 지원이 있었다면 채택하기가 더 쉬웠을 것입니다.

그리고 @cbazza 감사합니다 :)

@yuriy-manifold

여기 있는 누구도 JSX React가 고전적인 React보다 개선되었다는 점을 의심하지 않습니다. 그러나 내가 말했듯이 그 솔루션은 기본 플랫폼의 속성과 관련된 문제 때문에 만들어졌습니다. Flutter에는 이러한 속성이 없습니다.

질문은 'JSX가 React에 도움이 되나요?'가 아닙니다. 질문은 'JSX와 같은 것이 Flutter에 도움이 되나요?'입니다.

나는 대답이 아니오라고 생각합니다.

고려해야 할 몇 가지 다른 사항이 있습니다.

• 앱 코드에서 레이아웃 사양을 분리하면 코드를 미래에 대비할 수 있습니다. 예를 들어 이 Dart 2 구문 제안은 업그레이드 가능한 pragma에 따라 JSX와 같은 불가지론적 형식의 Dart 코드로 변환된 경우 build 메서드에 영향을 미치지 않습니다.
• 레이아웃을 마크업으로 정의하면 (상태 저장/가상화) 위젯 엔진과 React의 ReactDOM 및 React Native 관계를 통해 렌더링 엔진을 분리할 수 있으므로 잠재적으로 위젯을 새 플랫폼으로 더 쉽게 이식할 수 있습니다.
• 마크업 형식을 정의하면 기존 레이아웃(예: Sketch 또는 기타 디자인 도구)을 Flutter로 쉽게 이식할 수 있습니다.

트랜스 파일러 cbazza로 작업하기 좋습니다.

@Rockvole , 감사합니다.

커뮤니티와 UI를 그런 식으로 구축하려는 사람들을 위한 작업에 감사드립니다. 하지만 Flutter에서 그런 것을 강제로 사용하지 않기를 진심으로 바랍니다 :-(((

@zoechi님 , 감사합니다. 예, JSX를 사용하는 사람들을 위한 또 다른 옵션일 뿐입니다. 그것이 당신의 일이 아니라면 당신이하고있는대로 계속하십시오. 거기에는 아무 것도 바뀌지 않습니다.

Flutter 패턴을 지원하기 위해 새로운 JSX 구문을 발명할 필요가 없다고 생각합니다.

@alexkrolick 예, 명명된 매개변수에 대해 렌더링 소품을 사용할 수 있지만 위치 매개변수에 대해 할 수 있는 일은 없습니다. 핵심은 모든 것을 위해 작동하도록 트랜스파일러에서 어떤 것도 하드 코딩하고 싶지 않다는 것입니다.

Angular, React 등에 대한 약간의 경험이 있는 Flutter의 초보자인 저는 여전히 일반적인 Dart 방식과 Dart 2.0의 기타 방식이 이 DSX보다 낫다고 생각합니다. 일부 XML 및 CSS-ish 매개변수보다 더 합리적입니다.

@tenhobi , 확실히 DSX가 모든 사람을 위한 것은 아닙니다.

선택의 여지가 있다면 현재 모델을 고수할 것입니다.

@b-strauss, 이것은 대체품이 아니라 JSX를 좋아하는 사람들을 위한 옵션입니다.

사랑과 미움이 있지만 대부분의 의견은 일반 Dart보다 JSX의 유용성에 대해 다릅니다.

@lukaspili , DSX는 JSX를 사랑하는 React Native 사람들을 위한 것입니다. 이점이 보이지 않으면 사용하지 마십시오. DSX 대 일반 Dart가 아닙니다. DSX 대 JSX입니다. 2가 가까울수록 좋습니다.

좋은 소식은 이것이 Flutter 팀(이 스레드를 기반으로 하지 않을 가능성이 높음)에 의해 채택되었지만 아무도 강제로 사용하지 않는다는 것입니다. 옵션입니다. 왜 일부 사람들은 당신이 좋아하지 않는 구문으로 코드를 작성하는 것을 좋아할 정도로 감정적으로 부담을 느끼는지 이해가 되지 않습니다...

@tehfailsafe , 들어주셔서 감사합니다!!! React Native 사람들을 정말 행복하게 만드는 것에 대해 왜 그렇게 큰 저항을 했는지 당신은 머리에 못을 박았습니다.

나는 다른 사람들이 무엇을 좋아하든 좋아하지 않든 상관하지 않는다. 하지만 저는 응용 프로그램을 진행하는 데 도움이 되는 기능에 관심이 있습니다. 리소스가 제한되어 있으며 적절한 비디오/스트림 플레이어, 기본 하위 보기 및 일부 벡터 그래픽 형식을 사용하는 것이 좋습니다.

@b-strauss, React Native 팬이 Flutter로 이동하면 이러한 다른 필요한 작업을 도와줄 수많은 사람들이 있을 것입니다. 우선순위 1은 React Native에서 마음 점유율을 훔치고 React Native 사람들이 최대한 쉽게 이동할 수 있도록 하는 것입니다.

반면 Flutter에는 마크업 언어가 없습니다. 덜 역동적이고 덜 표현적인 것에 자원을 투자할 이유를 아직 보지 못했습니다.

@b-strauss, DSX는 어떻게 일반 Dart보다 '덜 다이내믹하고' '덜 표현력이 있습니까'? DSX는 Dart가 트랜스파일러를 시도하지 않았다는 것입니다.

@yuriy-manifold 감사합니다.

질문은 'JSX가 React에 도움이 되나요?'가 아닙니다. 질문은 'JSX와 같은 것이 Flutter에 도움이 되나요?'입니다.

@b-strauss, 물론입니다. 현재 Flutter 개발자에게는 도움이 되지 않지만 도구에서 CSS를 출력할 수 있는 디자이너에게는 매우 유용하며 React Native 플랫폼에 속해 있는 사람들에게는 매우 유용합니다.

@alexkrolick , 아주 좋은 관찰입니다.

@cbazza

이것은 대체품이 아니라 JSX를 좋아하는 사람들을 위한 옵션입니다.

알겠습니다... 그런 식으로 영향을 미치지는 않겠지만, 앞서 말했듯이 지금은 Flutter 앱을 만들어야 하는 누락된 기능이 있습니다.

React Native 팬이 Flutter로 이동하면 다른 필요한 일을 도와줄 수많은 사람들이 있을 것입니다. 우선순위 1은 React Native에서 마음 점유율을 훔치고 React Native 사람들이 최대한 쉽게 이동할 수 있도록 하는 것입니다.

그래서 당신은 flutter 팀이 의심스럽고 특정 웹 개발자 하위 집합의 일부를 끌어들일 수도 있고 그렇지 않을 수도 있는 기능을 보류해야 한다고 제안합니까?

DSX는 어떻게 일반 Dart보다 '덜 다이내믹하고' '덜 표현력이 있습니까'? DSX는 Dart가 트랜스파일러를 시도하지 않았다는 것입니다.

모든 DSL은 정의상 GPL보다 표현력이 떨어집니다. DSX를 사용하여 위젯을 조건부로 숨기려면 어떻게 합니까? 컬렉션을 반복하고 모든 요소를 ​​위젯에 매핑하려면 어떻게 해야 합니까? 스위치는 어떻게 사용합니까? 이제 GPL에 이미 있는 구문과 의미 체계를 구성해야 합니다. 그렇다면 처음에 DSL을 발명한 이유는 무엇입니까?

당연하지. 현재 Flutter 개발자에게는 도움이 되지 않지만 도구에서 CSS를 출력할 수 있는 디자이너에게는 매우 유용하며 React Native 플랫폼에 속해 있는 사람들에게는 매우 유용합니다.

그것은 질문이 아니었습니다... DSL은 당신이 지금 해결할 수 없는 어떤 문제를 해결합니까? 더 좋다는 말만 계속 하는건데 왜 더 낫지? DSX가 JSX 사람들을 끌어들일 것이라는 데는 의심의 여지가 없습니다. 나는 사람들이 다른 것을 좋아하지 않는다는 것을 압니다. 그리고 친숙함이 유일한 주장인 것 같습니다. 그렇다면 CSS를 사용하지 않는 이유는 무엇입니까?
JavaScript를 사용하지 않는 이유는 무엇입니까? Dart보다 더 많은 사람들이 이것을 사용하는 방법을 알고 있습니다.

익숙해지기 위한 목적으로 다른 것을 기반으로 시스템을 설계한다면 진정한 혁신이 아닙니다.

@b-strauss를 명확히 하기 위해 JSX는 함수 호출로 컴파일됩니다( createElement(ComponentClass) 에 대한 React 호출에서 Dart에서는 생성자여야 함).

<A property="a" />
new A(property: a)

<A property="a">
  <B />
  <C />
</A>
new A(property: a, children: <Widget>[new B(), new C()])

유일한 구성은 요소 이름+속성과 함수 호출+인수 간의 변환과 이스케이프된 표현식( {...} )입니다.

• DSX를 사용하여 위젯을 조건부로 숨기려면 어떻게 합니까?

(JS)
  { condition && <A /> }
  { condition ? <A /> : <B /> }

• 컬렉션을 반복하고 모든 요소를 ​​위젯에 매핑하려면 어떻게 해야 합니까?

(JS)
  { ['a', 'b'].map(i => <A property={i} />) }

• 스위치는 어떻게 사용합니까?
  JS에서와 같이 Dart에서 내가 아는 한 스위치 인라인은 표현식이 아니기 때문에 사용할 수 없습니다. 위젯 트리 외부에 있다면 스위치를 정상적으로 사용할 수 있습니다.

그래서 당신은 flutter 팀이 의심스럽고 특정 웹 개발자 하위 집합의 일부를 끌어들일 수도 있고 그렇지 않을 수도 있는 기능을 보류해야 한다고 제안합니까?

@b-strauss, React Native는 웹 개발이 아니라 Flutter의 주요 경쟁자인 크로스 플랫폼 모바일 개발입니다. 예, JSX는 광원과 같아서 많은 React Native 개발자를 끌어들일 것입니다. 2017년 8월에 이 기능을 요청했는데 말이 너무 많고 행동이 적습니다.

모든 DSL은 정의상 GPL보다 표현력이 떨어집니다. DSX를 사용하여 위젯을 조건부로 숨기려면 어떻게 합니까? 컬렉션을 반복하고 모든 요소를 ​​위젯에 매핑하려면 어떻게 해야 합니까? 스위치는 어떻게 사용합니까? 이제 GPL에 이미 있는 구문과 의미 체계를 구성해야 합니다. 그렇다면 처음에 DSL을 발명한 이유는 무엇입니까?

당신은 완전히 틀렸습니다. 좋은 소식은 나도 한 번 틀렸다는 것입니다. 전부는 아니지만 대부분의 DSL은 마크업에서 프로그래밍 구성을 다시 만들려고 시도하지만(매우 강력하지 않음), JSX는 마크업을 프로그래밍에 가져옵니다(호스트 언어를 최대한 활용). 차이점은 변형입니다. 모든 질문에 대한 답은 기본적으로 Dart에서 하는 방식을 사용하는 것입니다. Dart는 다트이기 때문입니다. 스프레드 연산자를 제외하고 '{}' 사이의 모든 것은 Dart 코드입니다. 모두 다트 표현식이지만 표현식을 반환하는 익명 함수를 사용할 수도 있습니다. 트랜스파일러 태그(\) 위젯의 새로운 기능입니다(new Text()).

DSL은 현재 해결할 수 없는 어떤 문제를 해결합니까?

0과 1을 사용할 수 있는데 왜 Dart를 사용합니까? 그게 컴퓨팅 문제를 해결하는 데 필요한 전부가 아닙니까?

더 좋다는 말만 계속 하는건데 왜 더 낫지?

나는 이전에 내 이유를 제시했고 여기에서 반복하지 않을 것입니다. JSX 사람들은 저에게 동의하지만 '각각 자신의 것'입니다.

DSX가 JSX 사람들을 끌어들일 것이라는 데는 의심의 여지가 없습니다. 나는 사람들이 다른 것을 좋아하지 않는다는 것을 압니다. 그리고 친숙함이 유일한 주장인 것 같습니다. 그렇다면 CSS를 사용하지 않는 이유는 무엇입니까?
JavaScript를 사용하지 않는 이유는 무엇입니까? Dart보다 더 많은 사람들이 이것을 사용하는 방법을 알고 있습니다.

예, CSS를 사용하는 것은 디자이너-개발자 워크플로를 용이하게 하는 데 적합합니다. DSX는 이를 지원합니다. Dart가 Javascript에 비해 장점은 실행 속도(성능)입니다.

익숙해지기 위한 목적으로 다른 것을 기반으로 시스템을 설계한다면 진정한 혁신이 아닙니다.

당신은 당신의 잠재력을 최대한 발휘하는 것을 방해하는 잘못된 편견으로 가득 차 있습니다. 마음을 열고 다양한 시도를 해보세요.

@alexkrolick , 자세한 내용 감사합니다.

@cbazza

당신은 당신의 잠재력을 최대한 발휘하는 것을 방해하는 잘못된 편견으로 가득 차 있습니다. 마음을 열고 다양한 시도를 해보세요.

지금 이 문제의 구독을 취소하겠습니다. 여기나 어디에서나 다시는 저를 언급하지 마세요, thx.

@b-스트라우스

미안해요, 당신의 기분을 상하게 할 생각은 없었어요... 그냥 내 자신의 좌절감을 다스리려고 애쓰면서 당신을 부드럽게 안내하려고 했던 것뿐이에요. 우리는 결국 모두 인간입니다.

@cbazza 이메일을 보내주시겠습니까? [email protected]

이미 이전 스레드에서 이 제안을 했지만 여전히 중요한 포인트라고 생각합니다.

new/const 를 사용할 필요가 없는 IMHO는 이미 많은 도움이 되었습니다. 다트 형식이 나무를 형식화하는 방식에 정말 어려움이 있습니다. 다음과 비교하여 트리 구조 IMHO를 충분히 강조하지 않습니다.

    return Scaffold(
      appBar: AppBar(title: Text("WeatherDemo")),
      resizeToAvoidBottomPadding: false,
      body: 
        Column(children: <Widget>
        [
          Padding(
            padding: const EdgeInsets.all(16.0),
            child: 
            TextField(
                    key: AppKeys.textField,
                    autocorrect: false,
                    controller: _controller,
                    decoration: InputDecoration(hintText: "Filter cities",),
                    style:  TextStyle(fontSize: 20.0,),
                    onChanged: ModelProvider.of(context).textChangedCommand,
                    ),
          ),

JSX와 같은 구문을 사용하지 않으려는 플러터를 단순하게 만들기 위한 목적에 동의하고 여러 위젯으로 분할하는 개념도 지원하지만 이제는 MVC 시대가 jquery로 돌아간 것처럼 느끼게 합니다. 나중에 패딩, 테두리 및 중앙 레이아웃이 있는 간단한 위젯이 있는 시나리오에서는 많은 "}" 기호가 가독성에 심각한 영향을 미칩니다. 그러나 통합 위젯이므로 분할하고 싶지 않습니다. 해결책? 비록 영어는 서툴지만, 나는 내 생각을 표현하기 위해 노력합니다.

주님 우리 모두를 도우소서.

좋아, 이것은 아무데도 가지 않는다. 아무도 곧 입장을 바꾸려고 하지 않을 것 같습니다. 우리는 여기에서 일종의 타협에 도달해야 합니다. 물론 "pro-DSX" 대 "anti-DSX"는 실제로 원격으로 만족스러운 타협을 가지고 있지 않으며, 이는 실망스러운 현실입니다. 더 호환될 수 있도록 위치를 재구성할 수 있습니까?

@naiveaiguy "그들"은 DSX를 가질 수 있습니다.
Flutter 팀이 이를 구현하지 않으면 오픈 소스 이니셔티브가 될 수 있습니다.
그렇다고해서 지금과 같은 순수 Dart 접근 방식이 더 이상 작동하지 않을 것이라는 의미는 아닙니다.
두 세계는 공존할 수 있습니다.

나는 @zoechi 가 공존할 수 있다는 것에 너무 동의합니다...그게 그리고 이것이 오래된 스레드에서 해결되었다고 생각했습니다.

@lrhn

시민 여러분, 건설적이어야 합니다. 우리는 여기에서 스타일에 대해 논의하고 있습니다. 매우 주관적인 것이므로 모든 사람이 자신의 선호도를 아무리 좋아하더라도 본질적으로 다른 모든 사람보다 우월하지는 않습니다. 기존 및 제안된 구문에서 볼 수 있는 장점과 단점을 나열하십시오. 그러나 모든 사람이 동일한 방식으로 보는 것은 아니며 완벽하게 괜찮습니다.

브라보, 바로 그것입니다.

React에서는 4가지 방법으로 할 수 있습니다. (그리고 저는 오늘 다른 2가지 방법에 대해 알게 되었습니다!!!)

(1) JSX(내가 좋아하는 것)를 사용할 수 있습니다.
https://reactjs.org/docs/introducing-jsx.html

(2) Flutter와 유사한 원래 방식을 사용할 수 있습니다.
https://reactjs.org/docs/react-without-jsx.html

위의 링크 끝에는 2개의 유망한 커뮤니티 프로젝트도 언급되어 있습니다.

(3) React.js 마크업을 위한 하이퍼스크립트 구문
https://github.com/mlmorg/react-hyperscript

(4) 하이퍼스크립트에 대한 간결한 구문.
https://github.com/ohanhi/hyperscript-helpers

대안이 있다는 것은 좋은 일입니다. 검정색이면 원하는 색상으로 Ford를 구입할 수 있는 시대는 지났습니다. :)

@naiveaiguy 현재 접근 방식 과 DSX가 있는 경우 문제가 되는 이유는 무엇입니까?
(그것은 내가 당신의 downvotes에서 파생 된 것입니다)

@naiveaiguy "그들"은 DSX를 가질 수 있습니다.
Flutter 팀이 이를 구현하지 않으면 오픈 소스 이니셔티브가 될 수 있습니다.
그렇다고해서 지금과 같은 순수 Dart 접근 방식이 더 이상 작동하지 않을 것이라는 의미는 아닙니다.
두 세계는 공존할 수 있습니다.

나는 이것에 전적으로 동의합니다. 나는 그것이 즉시 사용 가능한 솔루션이 아니라 플러그 가능해야한다고 생각합니다. 작동하는 하나의 표준을 가지지만 추가 항목으로 경험을 사용자 정의할 수 있다는 것은 훌륭한 패러다임입니다. 그런 식으로 Flutter 팀은 더 관련성 높은 문제에 계속 초점을 맞출 수 있고 커뮤니티는 다양한 도구/솔루션을 실험할 수 있으며 DSX 또는 현재에 대한 다른 대안에 대해 더 많은 데이터와 경험을 가지고 토론할 수 있습니다. 메타.

대안이 있다는 것은 좋은 일입니다. 원하는 색상으로 Ford를 구입할 수 있었던 시대는 지났습니다.
블랙이면 좋아요 :)

사실입니다. 하지만 Dart/Flutter가 또 다른 JS/Web Frontend 생태계가 되는 것을 원하지 않는다는 데 모두 동의할 수 있다고 생각합니다. Flutter는 아직 베타도 끝나지 않았으며 우리는 이미 주관적인 것에 대해 2가지 표준을 갖기를 원합니다.

React에서는 4가지 방법으로 할 수 있습니다. (그리고 저는 오늘 다른 2가지 방법에 대해 알게 되었습니다!!!)

React에서 언급하지만 대부분은 커뮤니티 중심입니다. 좋은 중간. 이제 공식적으로는 React.createElement 와 JSX 방식(다른 하나의 래퍼인 JSX 방식)만 공식적으로 지원됩니다. JSX의 가치는 그 맥락에서 악명이 높지만 여기서는 그렇게 명확하지 않습니다. 이를 염두에 두고 하나의 공식 표준과 관련될 때마다 DSX를 참조하는 문서만 있으면 중간에 충족할 수 있습니까?

Flutter 팀은 개발자가 앱을 빌드하지 못하도록 막는 부족한 기능에 집중해야 한다고 생각합니다. 지도 지원을 추가할 수 없고 카메라 기능을 개발하는 데 2주가 걸린다면 관리자에게 Flutter를 추천할 수 없습니다.

나는 DSX의 문을 영원히 닫지 않을 것임을 명심하십시오. UI 구축을 위한 솔루션이 될 수도 있지만 결정을 내리기 위해서는 이를 실험하는 커뮤니티가 필요합니다.

@zoechi 개인적으로 저는 두 가지 아이디어가 현재 Flutter 상태에서 공존할 수 있다고 생각하지 않습니다. 우리는 이러한 특성을 일찍부터 분할하도록 권장해서는 안 됩니다. 하지만 현재로서는 이것이 유일한 타협점으로 보입니다.

@naiveaiguy

개인적으로 저는 두 가지 아이디어가 현재 Flutter 상태에서 공존할 수 있다고 생각하지 않습니다. 우리는 이러한 성격의 분리를 일찍부터 권장해서는 안 됩니다.

그들이 공존할 수 없는 이유에 대해 더 구체적으로 말씀해 주시겠습니까? (DSX가 단지 합성 설탕이라는 사실을 감안할 때; 또는 @emalamela 가 "현재 방식의 래퍼"라고 말한 것처럼).

또한 정확히 같은 것에 다른 구문을 제공하는 것은 왜 너무 이릅니다. 나는 기본적으로 왜 이것을 연기할 필요가 있는지 묻습니다. 지금은 아직 존재하지 않는 미래에는 무엇이 다를까요?

@emalamela

하지만 Dart/Flutter가 또 다른 JS/Web Frontend 생태계가 되는 것을 원하지 않는다는 데 모두 동의할 수 있다고 생각합니다.

개인적으로 저는 사람들이 Dart/Flutter로 할 수 있는 일에 제한을 두지 않습니다. 시장/커뮤니티가 결정하게 하십시오. 기본적으로 만들어진 것이 가치를 더하지 않는다면 사람들은 그것을 사용하지 않고 죽게 될 것입니다. 대중화된다면 커뮤니티에서 유용하고 가치있게 여겨졌기 때문이다. 지금 승자와 패자를 선택할 필요가 없습니다.

내가 Flutter를 시도하지 못하게 막는 유일한 이유는 그들이 JSX를 사용하지 않기로 선택했다는 사실입니다.
IMHO JSX는 구성 요소 계층 구조를 표현하는 최선의 선택입니다.

Flutter에 대해 듣고 시도해 보고 싶었지만 구문을 보는 순간 생각조차 하지 않고 즉시 중단되었습니다. 이것은 이것이 훌륭한 기술일 가능성이 있기 때문에 부끄러운 일입니다. 제품을 구축합니다.

저는 지난 2.5년 동안 React/React Native 개발을 해왔으며 생산성을 희생하면서 UI를 설명할 때 JSX 구문이 제공하는 이점을 많이 묻습니다. Flutter에 대한 모든 것을 배우고 이러한 기능이 기본적으로 지원되는 시점으로 전환할 가치가 있는지 연구하는 데 시간을 할애하는 것을 진지하게 고려할 것입니다.

이 때문에 Flutter가 잃고 있는 잠재적인 채택자/사용자/개발자의 수는 상상조차 할 수 없습니다. 다음 달에 다시 방문할 것입니다.

이 때문에 Flutter가 잃고 있는 잠재적인 채택자/사용자/개발자의 수는 상상조차 할 수 없습니다. 다음 달에 다시 방문할 것입니다.

네, 44 Mio 는 투표를 할 만큼 중요하다는 것을 알았습니다 :D

네, 44는 투표를 할 만큼 중요하다고 생각했습니다 :D

'upvote'로 정렬하면 이 기능 요청은 3131개의 열린 티켓 목록에서 7위에 나열됩니다.

https://github.com/flutter/flutter/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

@cbazza 이 기능에 대해 논쟁하고 싶지는 않지만 "x를 수행하지 않으면 끔찍하게 y가 발생할 것입니다"와 같은 의견은 우스꽝스럽습니다.

저는 지난 2.5년 동안 React/React Native 개발을 해왔으며 생산성을 희생하면서 UI를 설명할 때 JSX 구문이 제공하는 이점을 많이 묻습니다. Flutter에 대한 모든 것을 배우고 이러한 기능이 기본적으로 지원되는 시점으로 전환할 가치가 있는지 연구하는 데 시간을 할애하는 것을 진지하게 고려할 것입니다.

@소나예

생산성에 대해 언급하셨는데 JSX 대신 Flutter's Pattern을 사용하는 경우의 생산성 손실을 명확하게 보여주는 예를 제공할 수 있습니까? 예제는 해당 예제를 코딩할 수 있을 만큼 JS 와 Dart를 충분히 알고 있다는 기반으로 작성되어야 합니다. 나는 우리가 그것을 고려하지 않는다면 우리는 또한 같은 논의가 아닌 프로그래밍 언어를 비교하고 있다고 믿습니다.

'upvote'로 정렬하면 이 기능 요청은 3131개의 열린 티켓 목록에서 7위에 나열됩니다.

@cbazza

가장 많이 다운된 투표이기도 합니다. 상당히 논란이 되고 있습니다.

@에 말라멜라 ,

가장 많이 다운된 투표이기도 합니다. 상당히 논란이 되고 있습니다.

이 기능 요청은 현재 방식의 대안이며 현재 방식을 변경하지 않으므로 전혀 논란의 여지가 없어야 합니다. JSX/DSX가 마음에 들지 않으면 지금처럼 프로그래밍을 계속하십시오.

이른바 논쟁은 Flutter 팀이 커뮤니티가 DSX를 적절하게 수행할 수 있도록 작업을 수행해야 하기 때문에 존재합니다. Flutter 도구(컴파일러, 분석기, IDE 지원 등)가 소스 맵을 사용한 사전 처리를 지원했다면 DSX는 오래 전에 수행되었을 것이며 타사 개발자의 다른 언어 혁신/아이디어도 발생했을 것입니다.

new Card(
  child: Column(
    crossAxisAlignment: CrossAxisAlignment.start,
    children: <Widget>[
      AspectRatio(
        aspectRatio: 18 / 11,
        child: Image.asset('assets/diamond.png'),
      ),
      new Padding(
        padding: EdgeInsets.fromLTRB(16, 12, 16, 8),
        child: Column(
          crossAxisAlignment: CrossAxisAlignment.start,
          children: <Widget>[
            Text('Title'),
            SizedBox(height: 8),
            Text('Secondary Text'),
          ],
        ),
      ),
    ],
  ),
)

다음이 됩니다.

<Card>
  <Column crossAxisAlignment={CrossAxisAlignment.start}>
    <AspectRatio aspectRatio={18 / 11}>
      <Image src={asset('assets/diamond.png')} />
    </AspectRatio>

    <Padding padding={EdgeInsets.fromLTRB(16, 12, 16, 8)}>
      <Column crossAxisAlignment={CrossAxisAlignment.start}>
        <Text>Title</Text>
        <SizedBox height={8} />
        <Text>Secondary Text</Text>
      </Column>
    </Padding>
  </Column>
</Card>

@emalamela JSX 에 대한 찬성과 반대 논쟁은 토론으로 소진되었습니다. 찾아볼 수 있는 자료가 많이 있습니다. 저는 제 개인적인 의견을 공유할 뿐입니다.

첫째, 코드 가독성입니다. JSX의 UI 구조에 대한 명확하고 명확한 아이디어를 즉시 얻을 수 있습니다(몇 초 소요). 정신적 모달은 매우 시각적입니다. 둘째, 사용성. JS/Dart 또는 기본 API에 대한 지식이 없어도 JSX를 사용할 수 있다고 주장합니다. 이것은 이제 막 프로그래밍을 배우는 사람이나 우리 팀의 일부인 누군가에게 매우 적합합니다. 이제 디자이너는 UI를 코딩 할 수 있습니다.

애플리케이션에 대한 설명은 완전히 선언적입니다(단순히 표현적인 것이 아님). 수백 개의 구성 요소가 있는 대규모 프로젝트에서 작업할 때 UI를 설명하는 이 방법은 큰 차이를 만듭니다(정말 감사하게 여기려면 시도해야 함). JSX를 처음 보았을 때도 마음에 들지 않았습니다. 일단 사용해보니 딱 맞았습니다. 앞으로 UI를 이렇게 설명하고 싶은 것은 인터페이스 구축에 접근하는 방식에 있어 분명한 돌파구였습니다.

더 적은 줄의 코드를 작성하는 것이 아니라 "구문 설탕"을 사용하는 것이 아니라 인간을 위한 도구를 구축하는 것입니다. 나는 또한 모든 사람이 JSX를 사용해야 한다는 주장에 반대합니다. 이것은 터무니없는 일입니다. 많은 사람들(저를 포함하여)의 경우 JSX(또는 Flutter의 경우 DSX)가 될 것입니다. 그게 전부입니다.

저는 React에서 왔으며 Flutter를 처음 사용해 봅니다. flutter 팀에 JSX 구문이 없다는 것은 정말 이상한 일입니다. 진심으로 말입니다! JS 세계에서 JSX는 현재 모든 React 대안에서 매우 널리 퍼져 있습니다! JSX는 개발자에게 매우 친숙합니다. 이 커뮤니티를 성장시키는 데 도움이 될 수 있도록 최대한 빨리 구현해 주십시오.

JSX(또는 이 경우 DSX)가 이 문제에 대한 주석의 양을 찾는 것만으로 큰 문제임을 알 수 있습니다.

JSX는 사용해 보기 전까지는 당신이 사랑하는지 모르는 것입니다. 코드에 마크업이 있는 것이 처음에는 이상하지만 나중에는 멋집니다.

이미 플러터/다트를 알고 있는 사람들에게는 불필요한 것 같습니다. 이해합니다. 그러나 나처럼 다트를 만져본 적이 없는 사람에게는 JSX가 시작하기 훨씬 쉽고 그게 요점입니다. 더 많은 사람들이 와서 더 멋진 것을 만들기 시작하려면 도구가 더 쉬워야 합니다.

그리고 @eseidelGoogle (https://youtu.be/h7HOt3Jb1Ts?t=2m41s)이 다른 사람에게 말했듯이 "Flutter는 단일 코드베이스에서 iOS와 Android에 작성하는 방법입니다. 우리는 그것을 빠르고 쉽게 만들려고 노력합니다. ..] Flutter는 하드웨어에 이르기까지 모든 것을 이야기합니다 [...] 우리는 매우 계층화된 접근 방식을 가지고 있으므로 원하는 만큼 적게 또는 많이 사용할 수 있습니다. [...] 우리는 도구 에 많은 투자를 했습니다. ."

JSX를 구현해 주세요.

저는 Dart의 팬이자 react를 많이 사용하는 사용자이기도 합니다. 나는 항상 Dart가 JSX보다 더 간결하고 유지 관리하기 쉽다고 생각합니다. 따라서 JSX/DSX는 커뮤니티 방식으로 구현될 수 있고 구현되어야 한다고 생각합니다.

@rajaraodv Flutter가 반응형 스타일 프레임워크로 승격되었다고 해서 이것이 단지 ReactJS의 풍미라는 의미는 아닙니다.
대부분의 댓글에서 나는 사람들이 새로운 것이 그들이 이미 알고 있는 것과 같지 않다는 것을 받아들이는 데 어려움을 겪는다는 인상을 받습니다.

현재 상태를 잠시 동안 Flutter로 작업한 다음 JSX/DSX가 단순한 Dart보다 "개인적인 선호" 또는 "더 좋아졌기 때문에"가 아니라 사실적인 방식으로 더 나은 이유를 적절한 논거로 제공할 수 있습니다. .

@zoechi , 당신은 뭔가를 놓치고 있습니다: Flutter 문서에 따르면 flutter는 React에서 영감을 받았습니다.
아마도 그것은 내 문제 일뿐입니다. Dart 2 구문으로 되어 있어도 UI 코드를 읽기가 어렵다는 것을 정말 느낍니다.

Flutter는 React Native에서 영감을 받았습니다.

나는 그것이 "언어가 JS 대신 Flutter라고 불리는 것을 제외하고는 모든 것이 동일합니다"라고 말하는 방법을 알지 못합니다.

UI 코드를 읽기가 어렵다는 것을 정말 느낍니다.

그리고 그것에 대한 상상할 수 있는 유일한 솔루션이 DSX라고 주장합니까?

Flutter가 1.0도 아니고 IDE 지원이 시간이 지남에 따라 향상될 수 있다는 점을 고려하셨습니까?

빠른 수정("wrap xxx") 및 닫기 레이블과 같은 코드 편집기에서 더 나은 Flutter IDE 지원을 얻기 위해 최근에 취한 첫 번째 작은 단계만 있었습니다.

개발자 경험을 개선할 수 있는 무한한 가능성이 있으며 이 토론에서 대부분은 다음과 같습니다.
"Flutter는 아직 완벽하지 않으므로 DSX가 필요합니다."
일반적으로 DSX가 문제를 해결하거나 개선하는 방법 또는 이유에 대한 구체적인 논의가 없습니다.

@zoechi ,

현재 상태를 잠시 동안 Flutter로 작업한 다음 JSX/DSX가 단순한 Dart보다 "개인적인 선호" 또는 "더 좋아졌기 때문에"가 아니라 사실적인 방식으로 더 나은 이유를 적절한 논거로 제공할 수 있습니다. .

다시 한번 Plain Dart 또는 DSX는 단순히 스타일의 문제이며 어느 것이 더 낫다는 논쟁의 여지가 없습니다. 그것은 단지 개인적인 취향이며 사람들은 하나 또는 다른 것을 선택하는 이유가 있습니다.

React World에서 일어난 일은 JSX를 사용하고 나면 다시 돌아가지 않는다는 것입니다. 다른 사람들이 위에서 언급했듯이 잠시 사용하면 JSX에 푹 빠지게 됩니다. JSX는 React's World(Typescript, Vue) 외부의 다른 사람들이 채택했으며 Flutter에 매우 적합합니다.

그리고 그것에 대한 상상할 수 있는 유일한 솔루션이 DSX라고 주장합니까?

커뮤니티에 필요한 것은 DSX 또는 더 나은 것을 커뮤니티에서 개발하고 Flutter(디버거, 자동 완료 등).

개발자 경험을 개선할 수 있는 무한한 가능성이 있으며 이 토론에서 대부분은 다음과 같습니다.
"Flutter는 아직 완벽하지 않으므로 DSX가 필요합니다."
일반적으로 DSX가 문제를 해결하거나 개선하는 방법 또는 이유에 대한 구체적인 논의가 없습니다.

물론, 이 티켓은 일반적인 '개발자 경험 개선'에 관한 것이 아닙니다. 이것은 매우 구체적이며 Flutter에서 JSX 지원을 받는 것에 관한 것입니다. 커뮤니티는 DSX를 일반 Dart 방식의 대안으로 원합니다.

나는 이것을 사용하는 것을 볼 수 없다(그러나 나는 그것을 시도할 용의가 있다). 나는 이것이 은총알이라고 생각하지 않지만, 할 가치가 있는 열정이 너무 많습니다.

커뮤니티가 원하는 것을 구축할 수 있도록 Google이 언어 장애를 제거해야 한다고 생각합니다.

저는 Google의 Flutter/Dart 팀 외부에 있는 누군가가 Dart/Flutter에 대해 JSX와 유사한 것을 작성하는 데 방해가 되는 장애물에 대해 알지 못합니다. 누군가가 시도한다면 버그 를보고 싶습니다. (이 매우 긴 버그의 모든 단어를 읽지 않았다는 것을 인정하기 때문에 위의 주석에서 놓쳤을 수도 있습니다.) :)

감사 해요! 그런 열정을 보니 반갑습니다!

@eseidelGoogle ,

Intellij 및/또는 VS Code(Dart-Code 포함)는 어떻게 중단점을 설정하고 .dsx 파일에서 코드를 단계별로 실행할 수 있습니까? (이것은 .dart 파일이 아님을 의미합니다). .dsx 파일의 자동 완성 기능은 어떻습니까(.dart 파일에서와 같이)?

도구에 많은 투자를 했지만 도구는 Dart/Flutter로 원활하게 변환되는 DSX와 같은 새 언어의 사전 처리(소스 맵 포함)를 지원하지 않습니다.

트랜스파일러를 사용할 수 있지만 완전히 통합하는 쉬운 방법은 없습니다.
https://spark-heroku-dsx.herokuapp.com/index.html

추신: 이 티켓은 댓글의 절반에 불과합니다!!!
https://github.com/flutter/flutter/issues/15922

@cbazza 어딘가에 해당 컴파일러가 있는 리포지토리가 있습니까? 코드를 공유하고 커뮤니티를 해킹에 참여하게 하면 완벽하지 않더라도 좋을 것입니다.

@jonahwilliams , DSX 트랜스파일러 코드는 너무 이르기 때문에 릴리스되지 않았습니다.
손으로 쓴 2개의 동등한 파일(.dsx 및 .dart)을 사용하여 중단점, 스테핑, 자동 완성 등과 같은 사전 처리 기능을 테스트할 수 있습니다.

도구가 일종의 소스 맵으로 사전 처리를 지원하면 이를 트랜스파일러에 추가하고 차단을 해제할 수 있습니다. 이것은 또한 다른 사람들이 마음의 욕망을 실험할 수 있게 해 줄 것입니다.

나는 Flutter에서 일하지 않지만, 다른 사람들에게 이익을 주기 위해 특정 도구를 요구하는 것은 일종의 불합리한 것처럼 보이지만 또한 도구가 통합되기를 원하는 초기 소스 코드나 예제를 공개하는 것을 거부합니다.

그만한 가치가 있다는 점에서 저는 전처리 후크를 제공하는 언어나 툴킷에 대해 알지 못합니다. 아마도 단순하지 않기 때문일 것입니다. 언어와 구문 주위에 많은 경우와 가정이 있기 때문일 것입니다.

소스 맵(https://pub.dartlang.org/packages/source_maps)을 생성했다면 Dart/Flutter와 상관없이 IDE에서 최소한의 기본 지원을 얻는 것이 매우 간단하다고 생각합니다. 그러나 다시 말하지만, 이것은 도구의 기능과 작동 방식을 알지 못하는 모든 추측입니다.

@matanlurey , 소스 맵을 통한 전처리 지원은 특정 트랜스파일러에 의존하지 않는 일반적인 메커니즘입니다. 미래에 상상할 수 있는 모든 언어를 지원하기 위한 기능입니다. Chrome 브라우저/디버거는 이를 매우 훌륭하게 지원하며 JS로 변환되는 모든 언어를 디버깅할 수 있습니다.

테스트를 위해 소스 맵을 사용하는 방법을 보여주기 위해 간단한 종류의 변환기를 만들 수 있습니다. 예를 들어 원본 파일의 모든 줄 사이에 빈 줄이 있는 Dart/Flutter 코드를 생성하는 간단한 변환기를 작성하십시오. (.d2 => .dart, .d2는 Dart/Flutter 파일, out .dart 파일에는 원본 파일의 모든 줄 사이에 빈 줄이 포함됩니다.)

예, 테스트 파일에 대한 소스 맵 생성 작업을 할 수 있습니다.

Flutter는 현재 NativeScript, ReactNative, Android, Web 및 유사한 XML 레이아웃에 익숙한 기타 개발자를 만족시키려는 시도를 꺼립니다. 더 중요한 할 일이 있으니 해산하고 자자.

JSX Syntax를 지지하는 Amy가 계속해서 한탄하기 전에 Flutter로 며칠을 실제로 작업하기를 바랐습니다. 저는 Xaml 기반 시스템에서 왔지만 금세 익숙해졌습니다. 정말 시도해보십시오.

@escamoteur
이봐, 에스카모터. 제가 플러터를 배우는데 많은 시간을 들이지 않았다고 생각하시나요?
flutter.io/tutorials/layout/에서 "위젯 포장" 섹션의 끝 부분에 자습서에서 제공한 코드가 작동하지 않습니다.
Flutter 문제 블록에서 문제를 언급했지만 아무도 이에 대해 관심을 갖고 싶어하지 않습니다.

• 다트 코드: main.dart
  https://raw.githubusercontent.com/flutter/website/master/_includes/code/layout/pavlova/main.dart

• 펍스펙: pubspec.yaml
  https://raw.githubusercontent.com/flutter/website/master/_includes/code/layout/pavlova/pubspec.yaml

• https://flutter.io/tutorials/layout/

@JonathanSum 귀하의 의견이 이 문제의 주제와 관련이 있습니까?

@zoechi
escamoteur는 JSX Syntax의 지지자가 계속해서 한탄하기 전에 Flutter와 함께 며칠을 실제로 사용하기를 희망한다고 말했습니다.
이 댓글은 우리가 Flutter로 작업하는 데 정말 많은 날을 보냈고 JSX의 요청이 정말 마음에서 우러나온 느낌임을 보여줍니다.

Group Dart: "Dart 구문은 훨씬 낫고 JSX/DSX는 좋지 않습니다"
그룹 JSX/DSX: "JSX/DSX 구문은 훨씬 더 좋고 Dart는 좋지 않습니다."

이거 나만 볼 수 있는거 아니야? 양측은 자신의 입장에 대해 찬성과 반대 입장을 분명히 합니다. 여기서 잃어버린 것은 @cbazza 가 비판을 받았을 뿐만 아니라 그것에 대해 뭔가를 했다는 것입니다. Flutter를 활용하기 위해 웹 개발자/반응/반응 네이티브와 Flutter의 격차를 좁히려고 합니다.

그리고 내 2센트... 풀 스택 개발자로서 저는 다양한 언어와 접근 방식을 경험했습니다... JSX는 제가 가장 좋아하는 코드 작성 방법 중 하나이며 Darts에 대한 대체 구문이 있기를 바랍니다. 그리고 나는 현재 구문이 나쁘다고 말하는 것이 아니라 JSX 스타일을 선호한다는 것입니다.

JSX/DSX 그룹 의 이 인용문에 동의하지 않습니다.

다트는 좋지 않다

Dart는 매우 훌륭하고 강력한 언어이며 아무도 언어를 폄하하지 않습니다. 논의는 Dart에 관한 것이 아니라 오늘날 대부분의 UI 개발자가 이미 사용하고 있는 그 위에 합성 레이어이며 Flutter가 그런 것을 통합할 것을 제안합니다.

• Android에는 XML 레이아웃이 있습니다.
• iOS에는 스토리보드 XIB(XML)가 있습니다.
• GTK+에는 Pango 등을 위한 XML이 있습니다.
• Qt에는 QML(YAML과 유사)이 있습니다.
• Xamarin에는 XAML이 있습니다.

이러한 프레임워크와 언어의 대부분에는 View와 Controller 로직을 구분하는 UI 마크업 언어가 있습니다. 그런 다음 React는 (여기에서 제안하는) 다른 접근 방식과 함께 제공되며 RN이 사용자 성장 및 인기 측면에서 지금 날아가고 있다는 데 동의해야 한다고 생각합니다. 제가 틀릴 수도 있지만 주로 JSX 때문입니다.

...

Flutter 팀/사용자로부터 이런 종류의 피드백을 받아야 하는 것이 정말 미친 제안인가요?

@birkir 와 그들 모두는 Flutter에 \o/가 없는 많은 문제를 가져옵니다.
다른 언어는 필요하지 않습니다.
같은 언어라도 Flutter에서 보기를 분리할 수 있습니다.

@birkir 이 스레드는 Dart와 구문에 대한 100%입니다.

논의는 Dart에 관한 것이 아니라 오늘날 대부분의 UI 개발자가 이미 사용하고 있는 그 위에 합성 레이어이며 Flutter가 그런 것을 통합할 것을 제안합니다.

그래서 그것은 Dart에 관한 것이 아닙니다... 그러나 Flutter는 레이아웃을 위해 Dart 외에 다른 것을 사용해야 합니까? 다트와 관련이 없다고 주장하면서 다트가 충분하지 않다고 말하는 것 같습니까?

이 시점에서 중요하지 않다고 생각합니다. Flutter 팀은 이 피드백(JSX/DSX 접근 방식 요청 시)을 보았고 원래 경로를 계속 따르기를 원합니다. 나는 그것이 더 잘 처리될 수 있다고 생각하지만 그들이 솔루션을 만드는 커뮤니티에 반대하는 것 같지는 않습니다.

나는 또 다른 크로스 플랫폼 옵션이 있어서 기쁩니다... Apple이 다음으로 뭔가를 제공할 것입니까? 그리고 아마도 그들은 우리 중 많은 사람들이 react/react-native에 대해 좋아하는 것을 보게 될까요? 요리가 있으면 IDK.

Flutter 팀은 이 피드백(JSX/DSX 접근 방식 요청 시)을 보고

이 버그는 우리가 여기서 무엇을 하고 싶은지 알아내지 못했기 때문에 여전히 열려 있습니다. 우리는 사람들이 그것을 어떻게 사용하는지 보기 위해 실험(예: cbazza's)을 열심히 보고 있습니다. 우리는 언젠가 이와 같은 codegen 도구를 위한 빌드 시스템에 후크를 제공할 계획이지만 가까운 장래에 할 일은 아닙니다. 장기적으로 우리는 여기에서 배운 것을 언어로서의 Dart의 발전에 영향을 미치는 데 사용하기를 희망합니다. 이것은 E4X/H4X/JSX/DSX와 같은 것을 Dart 자체에 추가하는 것을 의미할 수 있습니다. 아니면 아무도 실제로 그것을 사용하지 않는다는 것을 알게 되어 아무 것도 하지 않을 것입니다. 또는 모든 사람이 다른 것을 필요로 하므로 codegen 후크 및 cbazza와 같은 사용자 정의 패키지가 답입니다. 우리는 아직 모른다.

@jstansbe - Apple은 크로스 플랫폼이 iPhone, IPad 및 Mac OS를 의미한다고 생각합니다. 그들은 플랫폼을 가로 질러 무언가를 만드는 것보다 벽으로 둘러싸인 정원 위에 포탑을 추가 할 가능성이 더 큽니다. :)

다른 방식으로 위젯을 들여쓰고 형식을 지정할 수 있다면 jsx와 더 유사하고 xml 및 html(거의 모든 Android 개발자)에 대한 경험이 있는 사용자에게 친숙할 것입니다. Codelab 에서 이 코드를 확인하세요.

return new Container(
    margin: const EdgeInsets.symmetric(horizontal: 8.0),
    child: new Row(
      children: <Widget>[
        new Flexible(
          child: new TextField(
            controller: _textController,
            onSubmitted: _handleSubmitted,
            decoration: new InputDecoration.collapsed(
              hintText: "Send a message"),
          ),
        ),
        new Container(                                                 //new
          margin: new EdgeInsets.symmetric(horizontal: 4.0),           //new
          child: new IconButton(                                       //new
            icon: new Icon(Icons.send),                                //new
            onPressed: () => _handleSubmitted(_textController.text)),  //new
        ),                                                             //new
      ],
    ),
  );

이 다트를 jsx 코드로 확인

<Container margin="">
   <Row>
       <Flexible>
            <TextField   controller=""
                                onSubmitted=""
                                decoration="">
                 <OtherWidget></OtherWidget>

            </TextField>
        </Flexible>
   </Row>
</Container>

이 다른 형식과 더 HTML 같은 비교

  return Container(margin: const EdgeInsets.symmetric(horizontal: 8.0), child:
            Row(children: <Widget>[
                Flexible(child:
                    TextField(controller: _textController,
                              onSubmitted: _handleSubmit,
                              decoration: new InputDecoration.collapsed(hintText: "manda un mensaje"),),
                    ),
                Container(margin: const EdgeInsets.symmetric(horizontal: 4.0),child:
                     IconButton(icon: Icon(Icons.send),
                               onPressed: ()=>_handleSubmit(_textController.text),),)
              ],
            )
    );

이것은 조금 더 유사하며 이제 왼쪽에서 오른쪽으로 보기만 하면 html/xml/jsx와 유사한 다른 위젯을 알 수 있습니다.

요소(위젯) 속성은 새 위젯보다 들여쓰기가 더 많기 때문에 코드를 더 명확하게 이해하고 확인할 수 있습니다.

다른 IDE에서 이 형식에 대한 자동 들여쓰기를 할 수 있다면 좋을 것입니다. 지금은 손으로 이 작업을 수행합니다....

여기에 있는 모든 댓글을 읽고 내 친구(네이티브 모바일 앱 개발자, java/kotlin/objective-c/swift 녀석)와 개인적으로 토론한 후 내 관찰:

사람들은 두 가지를 요구합니다.

• __더 나은 가독성과 더 쉬운 쓰기__. 일부 구문 노이즈(괄호, 세미콜론, new , child , children )와 혼합된 깊은 중첩은 현재 코딩 방식에서 성가십니다.
• __코드에서 스타일/디자인을 분리합니다__. 시각적 분리는 읽기(명령형 코드와 스타일을 한 눈에 구분)에 좋고 실제 분리는 도구(예: Layout Editor가 있는 IDE)에 좋습니다.

또한 의견이 다른 두 그룹이 주로 있습니다.

• 문제를 해결하기 위해 다른 복잡성을 도입하지 않고 현재 구문을 개선합니다.
  이 방향으로 이미 몇 가지 개선 사항이 있습니다. 예를 들어, 옵션 new , Dart 2.0의 const 및 제안된 virtual "closing tag" comments 기능입니다.
• 문제를 해결하기 위해 추가 마크업 언어(JSX와 같은 또는 XML과 같은)를 도입합니다.

현재로서는 어느 것이 더 낫다고 쉽게 결론을 내릴 수 없습니다. 따라서 커뮤니티가 먼저 실험을 하고 나중에 최종 결정(수락 또는 거부)을 내리도록 하세요.

@hooluupog 가상 닫기 태그 주석은 이미 IntelliJ, AS, VSCode에서 잠시 동안 작동합니다.

@Hixie

이 버그는 우리가 여기서 무엇을 하고 싶은지 알아내지 못했기 때문에 여전히 열려 있습니다. 우리는 사람들이 그것을 어떻게 사용하는지 보기 위해 실험(예: cbazza's)을 열심히 보고 있습니다.

사람들은 내 실험을 Flutter에 지금 매끄럽게 포함할 수 없기 때문에 사용할 수 없습니다. 그래서 사람들이 가능성만 볼 수 있는 외부/온라인 실험으로 남아 있습니다.

우리는 언젠가 이와 같은 codegen 도구를 위한 빌드 시스템에 후크를 제공할 계획이지만 가까운 장래에 할 일은 아닙니다. 장기적으로 우리는 여기에서 배운 것을 언어로서의 Dart의 발전에 영향을 미치는 데 사용하기를 희망합니다.

사전 처리를 지원하기 위해 빌드 시스템이 변경될 때 약간의 움직임을 예상할 수 있는 시간에 대해 좀 더 구체적으로 말씀해 주시겠습니까? 우리는 한 달, 분기, 6개월, 1년, 2년, 10년, 희년 등을 말하고 있습니까?

이것은 E4X/H4X/JSX/DSX와 같은 것을 Dart 자체에 추가하는 것을 의미할 수 있습니다.

JSX/DSX에는 의미 체계가 없고 엔진에 의해 구현되거나 언어에 통합되지 않기 때문에 Dart 언어를 변경할 필요가 없음을 확인하려면 JSX 사양의 맨 위 단락을 읽으십시오. 전처리기(트랜스파일러)에서 사용하기 위한 것입니다. DSX는 웹에서 Flutter와 함께 사용하여 React-Dart를 React.js와 정확히 같지만 Dart 언어로 만들 수 있습니다.

https://facebook.github.io/jsx/

아니면 아무도 실제로 그것을 사용하지 않는다는 것을 알게 되어 아무 것도 하지 않을 것입니다.

어떻게 사람들이 처음에 사용할 수 없는 것을 사용하고 나서 사람들이 그것을 사용하지 않기 때문에 아무것도 할 필요가 없다고 결론을 내릴 수 있습니까? 이것은 '여행 금지'... '단어의 순환 사용'에 대해 SNL에서 Melissa McCarthy의 Sean Spicer 사칭을 너무 많이 생각나게 합니다. :)

https://www.youtube.com/watch?v=1Dvo6EHEJQE&t=48s

또는 모든 사람이 다른 것을 필요로 하므로 codegen 후크 및 cbazza와 같은 사용자 정의 패키지가 답입니다. 우리는 아직 모른다.

실험을 가능하게 하려면 전처리 기능이 절실히 필요합니다. 그것 없이는 아무것도 발전하지 않으며 새로운 것을 배우지 못할 것입니다.

사람들이 내 실험을 사용할 수 없습니다.

나는 당신이 사람들이 완전히 연마되지 않은 경우에도 기꺼이 시도하려는 것을 과소평가한다고 생각합니다. 예를 들어 누군가가 flutter run 를 래핑하여 사전 처리를 먼저 수행한 다음 flutter run 를 호출하는 쉘 스크립트를 쉽게 작성할 수 있습니다. 비슷한 작업을 수행하기 위해 핫 리로드를 래핑하는 스크립트가 있습니다(분석기를 먼저 실행한 다음 통과하는 경우에만 핫 리로드 신호를 flutter 스크립트로 보냅니다).

빌드 시스템이 변경될 때 약간의 움직임이 예상되는 시점에 대해 더 구체적으로 말씀해 주시겠습니까?

실제로는 아니지만(예: 그러한 진술을 하는 것이 어려울 수 있는 이유는 https://en.wikipedia.org/wiki/Forward-looking_statement 참조), 아마도 앞으로 몇 주 동안은 아닐 것입니다.

Dart 언어를 변경할 필요가 없습니다

그것은 정말로 가능합니다. 저는 이러한 실험을 기반으로 "아무것도 하지 않음"에서 "언어 구문에 급진적인 새 기능 추가" 및 그 사이의 모든 것에 이르기까지 많은 결론에 도달할 수 있다고 말하고 있습니다. 요점은, 우리는 아직 어떤 결정도 내리지 않았으며 이러한 모든 토론과 실험을 기반으로 해야 할 일을 배우는 데 매우 열려 있습니다.

백로그에 JSX를 추가하고 백만 개 이상의 다른 긴급 요구 사항과 함께 검투사 스타일로 경쟁하게 하시겠습니까?

React는 웹용으로 작성되었으므로 HTML 작성을 위한 간단한 솔루션이 필요합니다. JSX는 UI 작성을 위한 최고의 솔루션이기 때문에 인기를 끌지 못했지만 HTML을 작성하기 위한 최고의 솔루션이기 때문입니다.

Flutter에는 그런 제약이 없으므로 잘못된 이유로 평범하고 장황한 솔루션으로 안주해서는 안 됩니다.

장황함을 줄이고 싶다면 Anko(https://github.com/Kotlin/anko/wiki/Anko-Layouts)에서 영감을 얻고 싶습니다. 여기에서 새 지역 변수를 어디에서나 정의하고 일반 for 루프를 사용하여 자식 목록을 동적으로 구성할 수 있으므로 코드를 더 쉽게 따라갈 수 있습니다. 또한 각 중첩 수준이 어쨌든 이미 람다 함수이기 때문에 LayoutBuilder는 보기에 더 쉬워집니다(추가 빌더 람다를 전달할 필요가 없음). 어쨌든 이것은 영감을 위한 것이며 Flutter가 1:1로 복사해서는 안 된다고 생각합니다.

React는 웹용으로 작성되었으므로 HTML 작성을 위한 간단한 솔루션이 필요합니다. JSX는 UI 작성을 위한 최고의 솔루션이기 때문에 인기를 끌지 못했지만 HTML을 작성하기 위한 최고의 솔루션이기 때문입니다.

React Native는 웹 개발이 아니며 HTML을 사용합니다. 숙련된 React 개발자에게 물어보면(또는 이 스레드와 다른 JSX 스레드를 완전히 읽어보세요) 많은 React 개발자가 JSX를 UI를 작성하는 가장 좋은 방법으로 간주한다는 것을 알게 될 것입니다.

여기에서 새 지역 변수를 어디에서나 정의하고 일반 for 루프를 사용하여 자식 목록을 동적으로 구성할 수 있으므로 코드를 더 쉽게 따라갈 수 있습니다.

이 문장은 당신이 JSX를 모른다는 것을 분명히 보여줍니다. JSX(DSX에서와 같이)는 호스팅 언어(Javascript/Dart)의 모든 프로그래밍 구성(for-loop 등)을 사용합니다.

이 티켓은 JSX와 유사한 기능에만 관심이 있습니다. 다른 접근 방식(예: Anko)의 경우 토론을 위해 고유한 티켓을 만드십시오.

React Native는 웹 개발이 아니며 HTML을 사용합니다. 숙련된 React 개발자에게 물어보면(또는 이 스레드와 다른 JSX 스레드를 완전히 읽어보세요) 많은 React 개발자가 JSX를 UI를 작성하는 가장 좋은 방법으로 간주한다는 것을 알게 될 것입니다.

React는 React Native보다 오래 전에 나왔습니다. JSX의 원래 디자인은 기본 UI가 아닌 Rendering HTML을 기반으로 합니다. JSX가 무엇을 더 잘하는지에 대한 하나의 설득력 있는 주장을 보여줄 수 있는 사람은 아무도 없었습니다. 비교함으로써

new Scaffold(
  appBar: new AppBar(
    title: new Text(widget.title),
  ),
  body: new Column(
    child: ...,
  ),
)

에게

<Scaffold
    appBar={<AppBar title={<Text>{widget.title}</Text>} />}
  >
  <Column>
    ...
  </Column>
</Scaffold>

최신 비교를 수행하지 않았으며 단순히 한 줄에 더 많은 항목을 입력하고 있습니다. 다음과 비교해야 합니다.

Scaffold(
  appBar: AppBar(title: Text(widget.title)),
  body: Column(
    child: ...,
  ),
)

모든 못생긴 {<{<>} />} 및 닫는 </...> 태그가 어떻게 사라졌는지 확인하십시오.

이 문장은 당신이 JSX를 모른다는 것을 분명히 보여줍니다. JSX(DSX에서와 같이)는 호스팅 언어(Javascript/Dart)의 모든 프로그래밍 구성(for-loop 등)을 사용합니다.

아니요, JSX 내에서 if 문이나 for 루프(또는 switch 또는 기타 문)를 사용할 수 없습니다.

function render(data) {
  return (
    <div>
      // This is impossible
      let total = 0;
      for (let item of data.list) {
        total += item.value;
        <div>{ total }</div>
        <div>{ item.name }</div>
      }
    </div>
  )
}

표현식만 허용됩니다. 따라서 조건부 연산자( c ? x : y , 이는 else if 를 매우 보기 흉하게 만듭니다) 및 Array.map 등(또한 매우 보기 흉할 수 있음)을 사용하거나 코드의 일부를 다음 위치로 이동해야 합니다. 렌더 함수의 상단 또는 별도의 도우미 함수로. 물론 Flutter도 마찬가지입니다. Anko는 이러한 제한이 없으며 (일부) UI 코드를 보다 자연스럽게 작성합니다.

JSX 도입에 대한 토론에서 이것이 실제로 최상의 솔루션인지 또는 더 나은 솔루션을 찾을 수 있는지 묻는 것이 매우 타당하고 필요하다고 생각합니다. 그렇지 않으면 잘못된 작업에 리소스를 낭비하게 됩니다.

React는 React Native보다 오래 전에 나왔습니다. JSX의 원래 디자인은 기본 UI가 아닌 Rendering HTML을 기반으로 합니다.

JSX의 원래 디자인은 UI 작업을 수행할 때 특별히 나타나는 트리 구조를 생성/조작하는 친숙한 방법에 관한 것입니다. 웹 개발, 기본 개발, 모든 UI 개발 등에 나타나는 구성 요소 계층 구조(https://facebook.github.io/jsx/)를 생각하십시오.

JSX가 무엇을 더 잘하는지에 대한 하나의 설득력 있는 주장을 보여줄 수 있는 사람은 아무도 없었습니다.

요점은 현재 방식을 대체하려는 것이 아니라 React 개발자에게 친숙한 대체 방식을 추가하려는 것입니다.

Anko 제안은 Android Kotlin 개발자에게 익숙할 것이므로 별도의 티켓에서 현재 Flutter 계층 구조와 작동하는 사양을 제안하세요. 사양의 온라인 버전을 확인하거나 시도하면 현재 Flutter 위젯 계층 구조를 생성/상호 운용할 수 있는지 확인할 수 있습니다.

아니요, JSX 내에서 if 문이나 for 루프(또는 switch 또는 기타 문)를 사용할 수 없습니다.

이 작업을 권장하는 것은 아니지만 가능합니다. 익명 함수를 만들고 호출합니다.

function render(data) {
  return (
    <div>
      { ()=>{
        // This is *not* impossible
        let divs=[];
        let total = 0;
        for (let item of data.list) {
          total += item.value;
          divs.push(<div>{ total }</div>);
          divs.push(<div>{ item.name }</div>);
        }
        return divs;
      }() }
    </div>
  )
}

JSX 도입에 대한 토론에서 그것이 실제로 최상의 솔루션인지 묻는 것이 매우 타당하고 필요하다고 생각합니다.

최상의 솔루션은 없습니다. Flutter 위젯에 직접 매핑되고 오버헤드를 추가하지 않는 친숙한 것을 사용하도록 선택하는 것이 전부입니다.

그건 그렇고, 내 온라인 변환기에서 다음을 시도하십시오.
https://spark-heroku-dsx.herokuapp.com/index.html

@<Scaffold>
  <appBar:AppBar>
     <title:Text [widget.title]/>
  </appBar:AppBar>
  <Column>
    {kids}
  </Column>
</Scaffold>@

그리고 당신은 얻을:

--------new Scaffold(
--------  appBar: new AppBar(
--------    title: new Text(
--------      widget.title,
--------    ),
--------  ),
--------  child: new Column(
--------    child: kids,
--------  ),
--------);

DSX는 JSX와 유사하지만 Dart & Flutter의 경우 위 링크에 설명된 고유한 기능이 있습니다.

이것을 볼 때 Android에서 xml 레이아웃의 플래시백을 얻습니다. 이것을 구현하는 것은 좋은 생각이 아니라고 생각합니다. 이제 new 및 const 를 쓰지 않아도 되므로 훨씬 보기 좋습니다.

@charafau 당신이 언급하는 "Android의 xml 레이아웃"의 예제/img/링크를 공유할 수 있습니까?

아니, @wkornewald. "JSX가 UI 작성을 위한 최고의 솔루션이기 때문에 인기를 끌지 못했지만 HTML을 작성하기 위한 최고의 솔루션이기 때문에" 인기가 없었다면, React는 왜 모바일 앱과 데스크탑 앱을 빌드하기 위해 여전히 JSX를 사용할까요? Github 데스크톱 애플리케이션, Walmart 크로스 플랫폼 모바일 앱, Tesla 앱, Skype도 RN에서 구축했습니다.

React의 개념은 컴포넌트에 관한 것이기 때문에 React는 JSX 태그에 for 루프를 넣지 않습니다. 위쪽은 로직, 아래쪽은 JSX로 항상 이렇습니다. 모든 것은 많은 구성 요소로 분리되어 큰 구성 요소로 함께 연결됩니다.

사실, JSX에 반대하는 대부분의 사람들은 JSX가 일종의 HTML, XML 또는 덜 장황한 솔루션이라고 추측할 수 있을 뿐입니다.

@JonathanSum

JSX에 반대하는 대부분의 사람들은 JSX가 일종의 HTML이라고 추측할 수 있을 뿐입니다.

오히려 개인의 취향 외에 JSX/DSX를 옹호하는 다른 주장이 없었기 때문이라고 생각합니다. 물론 위에서 이미 논의한 바와 같이 괜찮습니다. 그러나 JSX가 일반 Dart보다 나은 사실을 보여주는 좋은 사실적 논증 목록이 없을 때 사람들이 JSX를 이해하지 못한다고 해서 JSX에 반대한다고 암시하지 마십시오.

오히려 개인의 취향 외에 JSX/DSX를 옹호하는 다른 주장이 없었기 때문이라고 생각합니다.

실제로는 이전에 많은 것이 제공되지 않았으며 두 스레드를 완전히 읽으십시오. 나는 전에 이 2가지를 언급했다:
(1) 더 이상 '아동' 및 '아동' 물건 없음
(2) 제3자 도구가 조작하기 쉽습니다(분석, 분석 및 재생성).

(2)를 사용하면 마크업을 향상시켜 Dart만으로는 불가능한 일을 할 수 있습니다. 예를 들어 DSX의 스프레드 연산자 또는 더 작은 집합에서 많은 함수 매개변수 생성.

다른 분들이 좋은 점을 많이 알려주셨지만 굳이 따지려고 하지는 않습니다 ;)

(1) 언급한 바와 같이 이러한 사항은 Dart에서도 변경/개선될 수 있으며 이미 논의가 있었습니다. 이것은 Dart 2가 출시되기 전에는 일어나지 않을 것입니다.
DSX가 모든 종류의 새로운 기능을 허용하고 Dart가 내 생각에는 공정한 주장이 아니라고 가정하는 것만으로도 충분합니다.
(2) 나는 이것이 Dart로도 할 수 있다고 확신하며 물론 이미 Dart용 파서가 있습니다.

다른 분들이 좋은 점을 많이 알려주셨지만 굳이 따지려고 하지는 않습니다 ;)

나를 위해 그것들을 파헤칠 필요는 없지만, 이것은 자주 등장하며 당신이 실제로 유효한 주장을 가지고 있다는 것을 다른 사람들에게 확신시킬 수 있을 것입니다.
나는 토론을 따랐고 좋은 사실 근거가 기억나지 않으며 다른 사람들도 마찬가지일 수 있습니다. 요약하면 다음 질문에 대한 링크를 게시할 수 있습니다.

앞서 논의한 바와 같이 개인의 취향을 타당한 논거로 받아들일 수 있지만, 사실에 근거한 주장도 많다면 지적해달라고 요청하는 것이 타당하다고 생각합니다.

당신은 계속 '유효한 논증'을 요구하고 그들이 주어졌을 때 '미래의 Dart는 이것을 가질 것입니다' 또는 '이것은 유효한 논거가 아닙니다'라고 무시합니다.

사실은 현재 Dart/Flutter는 위젯을 빌드할 때 모든 곳에서 시끄러운 자식/자식을 갖고 있지만 XML/DSX는 그렇지 않습니다. 현재로서는 DSX를 사용하여 이 어린이/어린이 소음을 제거하는 것이 매우 타당한 주장입니다. 그것을 정당한 주장으로 받아들일 수 있습니까? (당신이 Dart가 미래에 그것을 가질 것이라고 말했다고 해서 그 주장이 무효가 되지는 않습니다).

또한 XML을 파싱하는 것이 전체 Dart 언어를 파싱하는 것보다 훨씬 간단 하고 모든 언어에는 XML 파서가 있는 반면 Dart만이 완전하고 완전한 Dart 언어 파서를 가지고 있다는 사실입니다. 이것도 유효한 주장이라고 볼 수 있습니까?

유효한 주장이 많이 있습니다. 그것들은 당신에게 유효하지 않습니다. 그래서 제가 그것에 대해 논쟁하는 것을 중단했습니다. 사람들이 말한 내용에 관심이 있다면 JSX에서 2개의 스레드를 완전히 읽으십시오. 나는 당신이 DSX를 사용하도록 설득하는 데 관심이 없습니다. 당신은 평범한 Dart에 만족합니다. 나는 아니다.

선택적 DSX 구문에 대한 인수:

1) React(웹 및 네이티브)에서 오는 더 많은 개발자를 온보딩 및 유치
2) React Native 구성 요소를 Flutter 위젯으로 이식하는 더 나은 경험
3) 위젯에서 자식/자식 속성의 일관성을 유지합니다.
4) 코드 가독성(의견적 주장)
5) 다트 린팅과 별도로 로직 린팅 보기
6) UI 구축 도구의 세계를 엽니다.
7) 전처리기를 위한 생태계를 엽니다.

DSX +1

DSX +1

찬반 양론을 많이 쓰고 싶었지만 이 모든 댓글을 읽으면서 모든 것을 계속해서 반복할 것 같은 느낌이 듭니다.
너무 순진하고 무지하지 마십시오. 아무도 DSX를 사용하여 UI를 작성하도록 강요당하지 않을 것이라고 말합니다. 이는 단순히 옵션(더 나은 대안)일 뿐입니다.
101203103 다른 방법으로 JS를 작성할 수 있는 이유가 있습니다.

음, DSX를 구문 분석하고 이를 일반 Dart 함수 호출로 변환하는 분석기 플러그인을 작성하는 옵션이 항상 있으므로 컴파일러가 추가 작업을 수행할 필요가 없습니다.

진짜 질문은 분석기 플러그인이 컴파일러의 컨텍스트 내에서 적용되는지 여부입니다.

제게 묻는다면 DSX는 이상적으로는 일종의 플러그인을 통해서만 옵트인되어야 합니다. Flutter 사용자뿐만 아니라 Dart의 서버 측 및 웹 사용자가 변경 사항에 적응해야 하므로 언어 ​​자체에 추가하는 것은 매우 불필요하다고 생각합니다. Dart로 작성된 대부분의 코드에는 XML 구문이 원격으로 필요하지도 않습니다. 따라서 모든 사람에게 XML 구문을 적용하는 것은 잘못된 결정입니다.

TLDR; DSX를 그렇게 나쁘게 만들고 싶다면 분석기 플러그인을 작성하고 Dart에 직접 가져오세요. 인터넷은 당신을 사랑할 것이고, 수천 개의 Github 별을 얻게 될 것이며, 마치 React처럼 느껴질 것입니다. 윈윈.

PS 나는 당신이 그것을하기 위해 경주 할 것입니다

음, DSX를 구문 분석하고 이를 일반 Dart 함수 호출로 변환하는 분석기 플러그인을 작성하는 옵션이 항상 있으므로 컴파일러가 추가 작업을 수행할 필요가 없습니다.

현재 다트 언어에서는 해킹 없이 이것을 구현할 수 있는 방법이 없습니다(경합 조건, 재귀 가져오기 및 기타 사항을 생각해 보세요). 이것은 모든 것이 예상대로 작동하는 수준, 핫 리로딩, 정적 분석 등이 통합되어야 합니다.

제게 묻는다면 DSX는 이상적으로는 일종의 플러그인을 통해서만 옵트인되어야 합니다. Flutter 사용자뿐만 아니라 Dart의 서버 측 및 웹 사용자가 변경 사항에 적응해야 하므로 언어 ​​자체에 추가하는 것은 매우 불필요하다고 생각합니다. Dart로 작성된 대부분의 코드에는 XML 구문이 원격으로 필요하지도 않습니다. 따라서 모든 사람에게 XML 구문을 적용하는 것은 잘못된 결정입니다.

스레드를 읽는다면 그것은 첫날부터 아이디어였습니다. 우리는 단지 transpiler를 만들기 위해 flutter/dart의 지원을 원합니다.

TLDR; DSX를 그렇게 나쁘게 만들고 싶다면 분석기 플러그인을 작성하고 직접 Dart에 가져오세요. 인터넷은 당신을 사랑할 것이고, 수천 개의 Github 별을 얻게 될 것이며, 마치 React처럼 느껴질 것입니다. 윈윈.

스레드를 읽으십시오. 이것은 @cbazza 에 의해 이미 수행되었습니다(분석기 플러그인이 잘리지 않음)

https://github.com/flutter/flutter/issues/11609#issuecomment -388484681

PS 나는 당신이 그것을하기 위해 경주 할 것입니다

엄청난! 이것이 어떻게 작동하는지에 대한 이론만으로도 흥미로울 것입니다.

SGTM. 그렇다면 우리 모두는 일종의 사전 처리 지원을 기다리고 있다고 생각하십시오.

생성자를 통해 매개변수를 전달하는 것보다 빌더 구문을 선호합니다.

<strong i="6">@override</strong>
Widget build(BuildContext context) {
    return container()
      .height(56.0)
      .padding(8.0)
      .decoration(BoxDecoration(color: Colors.blue[500]))
      .child(text("Hello world!")
                   .style(...)
                  .build());
}

https://fblitho.com/ 에서와 같이

Text.create(context)
    .text("Hello World")
    .textSizeDip(50)
    .build();

DSX +1

나는 JSX에 대한 주장을 이해하지만 XML을 프로그래밍 언어로 방해하는 생각을 싫어하는 많은 사람들(자체 포함)이 있다고 생각합니다. 그것은 단지 잘못된 느낌입니다(그러나 나는 다른 사람들이 같은 느낌을 갖지 않는다는 것을 완전히 이해합니다).

일단 구현된 기능을 제거하는 것은 거의 불가능하므로 사전 예방 원칙을 제안합니다. Flutter 앱이 빌드되는 방식을 크게 변경하기 전에 일부 최신 Dart 2 구문 기능이 어떻게 작동하는지 살펴보겠습니다.

@wstrange
나는 당신을 이해합니다. 나는 JSX에 반대하고 js를 xml/html과 혼합했습니다.... 그런 다음 시도했습니다. react와 함께 몇 달을 보낸 후, 저는 JSX와 사랑에 빠졌습니다. 두 가지 킬러 이점은 다음과 같습니다.

1. 새로운 구문 및 유틸리티 없음
2. 더 이상 변수, 함수 등을 전달할 필요가 없습니다.

@wstrange ,

일단 구현된 기능을 제거하는 것이 거의 불가능하다는 점을 감안할 때,

Google이 Chrome에서 MathML을 제거할 것이라고 누가 생각이나 했겠습니까?

Flutter 앱이 빌드되는 방식을 크게 변경하기 전에 일부 최신 Dart 2 구문 기능이 어떻게 작동하는지 살펴보겠습니다.

Flutter 앱이 빌드되는 방식에 대한 변경 사항이 전혀 아니며, 현재 방식을 변경하지 않는 대체 방식일 뿐이며 가장 중요한 것은 단순히 클래스 라이브러리와 다른 구문입니다. 간단한 트랜스파일러는 Flutter 클래스의 정보 없이 매핑을 수행하므로 현재와 미래의 Flutter는 물론 모든 사람의 코드에서 잘 작동합니다.

@베소노프

예, 몇 달 동안 작업하면서 React가 구성 요소 계층 구조를 처리하는 데 라이브러리가 얼마나 놀라운지 깨닫게 될 때까지 React를 모릅니다.

@cbazza Flutter에 대해 정확히 같은 말을 할 수 있습니다. 몇 주 동안 사용하면 JSX를 놓치지 않을 것입니다.

반응이 모든 것을 말해줍니다.

지금과 같이 +1 는 -1 $의 거의 두 배입니다.

@에스카모터 ,
예, 매우 공정한 진술이지만 저는 Flutter와 많은 시간을 보냈고 DSX가 그것에 추가할 가치를 확실히 알 수 있습니다. @leedstyh 가 알아차렸듯이 DSX 팬은 거의 2:1로 레이스를 이끌고 있는데, 이는 이 포럼의 사람들이 Flutter 사용자라는 점을 고려하면 매우 놀라운 일입니다.

질문이 있습니다:

DSX 구문을 사용할 때 내포된 자식이 Widget 유형이라고 암시적으로 가정합니다. 중첩된 자식이 Widget의 특정 하위 유형이 되기를 원한다고 명시적으로 지정하려면 어떻게 해야 합니까?

예를 들어, 내 사용자 정의 위젯의 자식이 컨테이너 목록만 허용하도록 하려는 경우 자식에 List<Container> 주석을 달 수 있으며 컨테이너와 다른 것을 입력하자마자 IDE에서 오류를 표시합니다. dsx를 사용할 때 이와 같이 유형 안전을 적용할 방법이 없다는 것을 알고 있습니다. 앱이 컴파일될 때 약간의 오류가 발생할 수 있지만 입력할 때 오류가 발생하는 것이 여전히 더 나은 경험이라고 생각합니다.

적어도 v1 릴리스 이후에는 UI를 선언하는 flutter 방법을 시도하고 익숙해질 시간을 모든 사람에게 주어야 한다고 생각합니다. 그러면 이 기능을 더 잘 볼 수 있습니다.

@산단겔 ,

아주 좋은 캐치!!! 나는 당신에게 내 가상 모자를 볼링합니다. 내 초기 프로토타입에는 처음부터 내가 알고 있었고 사람들이 찾아서 앞으로 나올 때까지 기다리는 몇 가지 구멍이 있었습니다. 나는 사람들이 기술에 대해 싸우는 대신 기술에 대해 논의하는 데 관심을 갖기를 바랐습니다.

이에 대한 해결책은 배열 유형을 네임스페이스의 다른 매개변수로 제공하는 것입니다. 네임스페이스가 커지면서 'children'의 약칭을 '*'로 설정할 수 있습니다.

https://spark-heroku-dsx.herokuapp.com/index.html 의 예제 2에서 작업이 기본 '위젯' 대신 '컨테이너'의 배열인 경우 다음 대안처럼 보일 것입니다.

        <actions:children:Container>
            <IconButton 
                icon={new Icon(Icons.search)}
                tooltip='Search'
                onPress={null}
            />
        </actions:children:Container>

        <actions:*:Container>
            <IconButton 
                icon={new Icon(Icons.search)}
                tooltip='Search'
                onPress={null}
            />
        </actions:*:Container>

안녕하세요 @cbazza , 응답해 주셔서 감사합니다.

귀하의 솔루션이 궁금합니다. w3shool-XML 네임스페이스 에 설명된 대로 xml 네임스페이스를 오용하고 있습니까?

네임스페이스는 주로 XML 문서에서 명명 충돌을 해결하는 데 사용된다고 명시되어 있습니다.

따라서 누군가 위의 XML을 읽으면 'actions' 네임스페이스의 'children' 네임스페이스 아래에 Container 태그를 선언한다고 생각할 수 있습니다. 중첩된 모든 자식이 컨테이너여야 한다고 강제하는 것은 아닙니다. 위의 설명을 읽지 않고 제안 구문을 처음 읽을 때 혼란스럽습니다.

우리는 더 나은 것을 가질 수 있습니까?

DSX는 XML이 아니라 XML과 유사하므로 Angular 템플릿 언어와 같은 XML 의미 체계를 따를 필요가 없습니다.

React-native에서 처음으로 JSX와 같은 구현을 지원했고 중첩된 객체를 좋아하지 않았지만 OOP를 즐기고 모든 것을 객체로 보기 시작했습니다!

React-native에서 온 사람들에게 이 플러그인을 강력히 추천합니다! https://marketplace.visualstudio.com/items?itemName=CoenraadS.bracket-pair-colorizer

@clarktank
react-native(JSX), Flutter(OOP) 및 하나에서 다른 것으로의 여정을 통해 경험을 확장할 수 있습니까?

@cbazza 각도 템플릿 구문은 xml 의미 체계를 따르고 각도 구문과 xml 문서 간에 충돌 사용 사례가 없다는 것을 알고 있습니다.

typescript에서는 일반 구성 요소 를 지원합니다.
그래서 나는 우리가 다음과 같은 것을 가질 수 있다고 생각합니다:

<children<Container>>
  <Container/>
</children>

그러나 다시 일반 구성 요소는 속성 입력을 유형 확인하는 데 사용됩니다. 위의 구문이 이 사용 사례에서 올바른 의미를 갖고 있는지 모르겠습니다.

저는 Flutter 팀이 JSX보다 낫다고 생각하는 UI를 선언하는 새로운 방법을 위해 특별히 현재 API를 만들었다고 생각합니다. JSX 구문을 현재 API에 바인딩하려는 모든 노력은 사용하기에 부자연스럽고/불편해 보이게 만듭니다.

반응이 모든 것을 말해줍니다.

지금과 같이 +1은 -1의 거의 두 배입니다.

이것은 아무 의미가 없습니다.

모든 Flutter 문제를 보고 있는 사람들을 제외하고는 이미 JSX에 익숙하고 명시적으로 찾고 있기 때문에 이 문제에 대해 두 배로 나타납니다. 따라서 이것은 오히려 _JSX와 같은 경험을 원하는 사람들이 -1로 투표한 모든 문제를 보는 사람들의 두 배를 의미합니다. (임호 +1에 투표하는 사람 중 일부는 실제로 플러터를 시도하지도 않았습니다)

@산단겔 ,

각도 템플릿 구문은 xml 의미 체계를 따르고 각도 구문과 xml 문서 간에 충돌 사용 사례가 없다는 것을 알고 있습니다.

물론 JSX는 네임스페이스를 사용하지 않으므로 관심 있는 XML 기능이 아닙니다.

<children<Container>>
  <Container/>
</children>

'자식'을 자체 태그로 분리했기 때문에 React의 새로운 Fragment 태그가 생각납니다. 장황함과 간결함 사이의 균형은 확실합니다.

저는 Flutter 팀이 JSX보다 낫다고 생각하는 UI를 선언하는 새로운 방법을 위해 특별히 현재 API를 만들었다고 생각합니다. JSX 구문을 현재 API에 바인딩하려는 모든 노력은 사용하기에 부자연스럽고/불편해 보이게 만듭니다.

Flutter가 코드에서 UI를 선언하는 방식에는 새로운 것이 없습니다. 아마도 DSX를 사용하는 것이 당신에게는 부자연스럽고 불편할 수 있지만 JSX 개발자에게는 그렇지 않습니다. JSX/DSX는 Flutter에 완벽합니다. 장갑처럼 딱 맞고 장갑이 마음에 들지 않으면 맨손으로 가세요 ;)

@a14n ,

이것은 아무 의미가 없습니다.

그것은 확실히 않습니다 !!! '느낌', '생각', ​​'용의자', '임호', '의견'으로 논쟁할 수 있지만 이것은 데이터, 구체적인 데이터 포인트입니다. 데이터가 쓸모 없으면 수집해서는 안 됩니다. 데이터는 당신의 그림을 그리지 않기 때문에 쓸모가 없다고 생각합니다.

@cbazza 자식/어린이를 위한 위젯의 하위 유형을 적용하는 것과 관련하여 위에서 질문에 답하려고 할 때 Dart 코드가 JSX보다 더 나은 작업을 수행하고 있다고 느낍니다.

DSX는 XML이 아니며 XML과 유사하므로 XML 의미 체계를 따를 필요가 없습니다.

물론 JSX는 네임스페이스를 사용하지 않으므로 관심 있는 XML 기능이 아닙니다.

확실하지 않지만 위의 귀하의 의견 중 일부를 읽었으며 JSX/XML 노드를 서로 바꿔서 언급한 것 같습니다. 어쨌든 개인적으로 네임스페이스를 솔루션으로 사용하는 것은 이상적이지 않다고 생각합니다.

그냥 비교

<actions:children:Container>

</actions:children:Container>

그리고

actions: <Container>[]

통사론.

@산단겔 ,

네, 이 경우에 태깅 구문이 더 장황합니다. 그래서 제가 어린이용 축약형을 '*'라고 언급한 이유입니다. 어쨌든 이 경우는 예외이며 규칙이 아닙니다. 대부분의 경우 '컨테이너'는 고사하고 '자식'도 지정할 필요가 없습니다. 그러나 가능한 모든 사용 사례를 포괄할 수 있는 기능이 있어야 합니다.

@a14n 투표는 투표입니다.

나는 당신의 감정을 존중합니다. 아마도 사실일 것입니다. 그러나 반대 비율(1:2)이 있더라도 이는 여전히 33%의 사용자 기반을 의미합니다. 33%가 작은 몫이라고 말할 수 있습니까?

JSX와 같은 경험을 원하는 사람들

예, 몇몇 사람들이 보고 있습니다. 이것은 또한 _JSX와 유사한 기능이 없기 때문에 사람들이 flutter를 선택하지 못하는 이유 중 하나임을 의미합니다.

Flutter는 모든 문제를 읽을 뿐만 아니라 더 많은 개발자를 목표로 합니다.

@jstansbe
저는 독학 프로그래머이며 대부분의 독학 사람들과 마찬가지로 Javascript로 시작했습니다.
그런 다음 React와 React-Native를 배우기 시작했습니다. 최근에는 특히 ES6 이후에 Javascript에 OOP 스타일이 추가되었다고 생각합니다.

그래서 나 같은 사람들은 OOP 스타일의 프로그래밍에 익숙하지 않습니다. React 네이티브 Component 는 Flutter의 Widgets 와 같은 클래스이지만.

JSX 종류는 순수한 OOP 그림을 숨깁니다. 기본적으로 후드 아래에서 일어나는 일을 숨깁니다. 참고: React는 웹 개발자를 위해 설계되었으며 웹 개발자는 html 구문에 익숙합니다. 이것이 웹 개발자들 사이에서 JSX가 인기 있는 이유입니다.

개인적으로 순수 OOP가 큰 프로젝트에 더 적합하다고 생각합니다.

@클락탱크 ,

컴퓨터 언어에 대해 논의할 때 다음 사항에 유의해야 합니다.
(1) 구문 - 언어를 구성하는 문자와 단어
(2) 의미론 - 해당 문자 및 단어의 의미

예를 들어, 많은 언어에서 함수 호출은 다음과 같습니다(즉, 다음 구문을 가짐).

a = someFunction(param1, param2)

이제 다른 언어가 함수 호출에 둥근 대괄호 대신 대괄호를 사용하기로 결정했다고 상상해 보십시오. 다음과 같이 보일 것입니다.

a = someFunction[param1, param2]

여기서 문제는 구문은 다르지만 의미는 동일하다는 것입니다. 내 말은 둘 다 기본적으로 함수 호출을 수행하지만 구문이 다릅니다.

JSX 종류는 순수한 OOP 그림을 숨깁니다. 기본적으로 후드 아래에서 일어나는 일을 숨깁니다.

전혀 사실이 아닙니다. JSX/DSX는 정확히 같은 것에 대한 다른 구문일 뿐입니다(의미는 동일합니다). JSX의 경우 XML 태그는 React 구성 요소를 생성합니다(순수 자바스크립트에서 수행할 수 있는 것처럼). DSX의 경우 XML 태그는 Flutter 위젯을 생성합니다(Pure Dart에서 할 수 있는 것처럼). 구문은 다르지만 정확히 동일한 것을 생성하므로 내부적으로 동일합니다.

참고: React는 웹 개발자를 위해 설계되었으며 웹 개발자는 html 구문에 익숙합니다. 이것이 웹 개발자들 사이에서 JSX가 인기 있는 이유입니다.

JSX는 웹, 모바일 또는 모든 UI 개발에서 구성 요소 트리 계층을 관리하는 좋은 방법이기 때문에 널리 사용됩니다. 아래 코드에서 드롭다운 구성 요소가 예를 들어 웹용인지 모바일용인지 알 수 없습니다.

https://facebook.github.io/jsx/

// Using JSX to express UI components.
var dropdown =
  <Dropdown>
    A dropdown list
    <Menu>
      <MenuItem>Do Something</MenuItem>
      <MenuItem>Do Something Fun!</MenuItem>
      <MenuItem>Do Something Else</MenuItem>
    </Menu>
  </Dropdown>;

render(dropdown);

개인적으로 순수 OOP가 큰 프로젝트에 더 적합하다고 생각합니다.

방법 것입니다? (JSX/DSX 또는 Pure Javascript/Dart를 사용하면 후드 아래에서 정확히 동일한 것을 생성한다는 점을 고려하면).

@cbazza

저는 거의 1년 동안 react-native를 사용했으며 Flutter/Dart를 시작할 때까지 JSX 요소가 인스턴스화되는 객체라는 사실을 전혀 몰랐습니다. 내 관점에서 볼 때 OOP 그림을 숨깁니다. 비록 당신이 말했듯이 의미적으로 후드 아래에서 같은 일을 합니다!

큰 응용 프로그램에서 JSX는 많이 중첩된 개체만큼 보기 흉할 수도 있습니다. 그래서 문법적으로, 나는 혼란스러울 수 있는 다른 스타일을 도입하는 것보다 일관성을 유지하고 싶습니다.

@클락탱크 ,

큰 응용 프로그램에서 JSX는 많이 중첩된 개체만큼 보기 흉할 수도 있습니다. 그래서 문법적으로, 나는 혼란스러울 수 있는 다른 스타일을 도입하는 것보다 일관성을 유지하고 싶습니다.

나에게 코드의 나머지 부분과 다르게 보이게 하는 것은 실제로 이점입니다.

(텍스트의 벽에 대해 미리 사과드립니다.)

Raw Dart 또는 JSX/DSX가 "더 나은"지 여부를 결정적인 소스라고 생각할 만큼 오랫동안 React-Native 또는 Flutter를 사용하지 않은 사람으로서 이 문제 스레드는 읽기에 다소 매력적이었습니다. 그래도 내 $0.02를 내려 놓고 싶은 몇 가지가 있습니다.

시작하기 위해 JSX가 실제로 무엇인지 그리고 이것이 개발자에게 어떤 이점이 있는지에 대해 다양한 사람들과 동의하고 있습니다. 무엇보다도 JSX는 기존 Javascript 코드에 인라인될 수 있는 "동적 HTML" 형식으로 설계되었습니다. React와 같은 JS 기반 웹 플랫폼에 없어서는 안 될 요소입니다. 웹 개발자가 엄청나게 기본적인 방식(또는 유일하게 약간 더 나은 jQuery 방식)과 씨름하지 않고도 DOM과 깨끗하고 효율적으로 상호 작용할 수 있다는 점입니다. 또한 JSX는 본질적으로 기본 데이터에서 쉽게 분리할 수 있는 UI 개발을 장려하여 잘 구성된 프로젝트 구조를 촉진합니다. 그런 환경에서 JSX는 생산성을 높일 수 있는 도구이며 이에 대해 논하는 것은 거의 불가능하다고 생각합니다.

해당 단락이 React-Native와 관련되는 방식은 모바일 개발 플랫폼임에도 불구하고 React의 직계 후손이라는 것입니다. 따라서 거의 모든 구문과 패러다임은 원래 웹 개발을 염두에 두고 만들어졌습니다. 그것은 의도적으로 설계된 것입니다 - RN의 전체적인 특징은 "React를 사용하여 플랫폼 간 모바일 앱을 생성"할 수 있다는 것이므로 사용할 때 웹 개발과 같은 느낌을 _추정_합니다. RN 앱도 대부분 Javascript로 작성되므로 JSX를 포함하는 것은 자연스러운 일입니다. JSX는 웹 개발에 도움이 되는 것과 거의 동일한 이유로 RN 개발을 돕습니다. (나는 이것이 적어도 RN에서 JSX 접근 방식이 기본 접근 방식보다 훨씬 더 자주 사용되는 큰 이유 중 하나라고 생각합니다. RN 자체는 웹 플랫폼처럼 _느끼고_하므로 보다 웹에 자연스럽게 접근할 수 밖에 없습니다. 우세하게 된다.)

반면 Flutter에는 그러한 디자인 철학이 없습니다. 순전히 네이티브 크로스 플랫폼 솔루션으로 의도되었으며 React-Native에서 영감을 받았다고 명시되어 있지만 웹 앱보다 네이티브 데스크톱이나 모바일 앱과 훨씬 더 유사하게 작성합니다. 또한 Javascript가 아닌 Dart를 사용하여 실행되며 JSX와 같은 것을 통합하는 관점에서 주요 고려 사항입니다. 하나는 JS DOM 함수가 끔찍하게 장황할 수 있지만(둘 다 함수의 디자인과 JS 언어 자체 때문에), 언어로서의 Dart는 깨끗한 UI 선언적 코드를 훨씬 더 용이하게 하는 반면 Flutter는 대부분의 경우 좋은 일을 합니다. UI 생성자를 간결하게 유지합니다. @sandangel 이 지적했듯이 Dart는 정적으로 유형이 지정된 언어이므로 JS와 같은 동적으로 유형이 지정된 언어용으로 설계된 JSX의 특성은 예를 들어 UI 생성자가 다음을 요구하는 경우에 걸림돌이 될 것입니다. 특정 유형의 위젯으로, 자세한 정보를 추가하는 유일한 솔루션입니다. 개인적으로, 시간이 지남에 따라 불가피하게 DSL이 부풀어 오르고 유지 관리가 어려워지는 솔루션처럼 느껴집니다. 사용.

따라서 JSX/DSX가 개인 취향의 문제를 넘어 Flutter 개발 생산성에 어떤 이점이 있는지 정말 모르겠습니다. 두 구문은 전체적으로 대략적으로 자세한 정도가 동일하며, 특정 사례에서 자세한 정보를 잃는 경우 명확성으로 보충합니다(예: 닫는 XML 태그). 웹 지향 배경(React/RN, Angular 등) 또는 기본 배경(Java/Kotlin/Swift, WPF/UWP 등)에서 Flutter에 오는 사람이 누구인지 결정하는 것으로 크게 요약됩니다. 그들이 선호하는 접근 방식. 이 스레드만으로도 처음에는 JSX에 대해 매우 회의적이었다가 몇 달 동안 사용하면서 "없으면 할 수 없다"라는 의견으로 바뀌었다는 사용자 스토리가 많이 있습니다. (비록 내 냉소적인 부분은 그들이 기회를 준다면 네이티브 Dart 접근 방식에 대해 똑같은 일이 그들에게 매우 잘 일어날 수 있음을 지적하고 싶어하지만.)

그렇긴 하지만, 나는 DSX가 네이티브 UI 생성자의 대안으로 Flutter 팀에서 공식적으로 지원되어야 한다는 데 동의할 수 없습니다. 타사 솔루션(및 실제로 구현하기 위한 @cbazza 의 모든 소품)으로서는 완벽하지만 웹 기술 기반이 아닌 플랫폼인 Flutter의 핵심 특성에는 실제로 맞지 않습니다. 따라서 자신의 프로젝트에서 DSX를 사용하고자 하는 모든 사람에게 더 많은 권한이 부여되지만 Flutter 팀이 시간을 할애할 수 있고 해야 하는 다른 더 중요한 일이 많다는 생각을 하고 싶습니다.

이제 DSX가 공식적으로 지원된다는 데에는 동의하지 않지만 일종의 공식 UI 형식이 있어야 한다고 생각합니다. @birkir 가 지적했듯이 데스크톱이든 모바일이든 거의 모든 주요 기본 UI 플랫폼에는 직접적인 코드 기반 접근 방식 외에 UI 형식이 있습니다(대부분은 어쨌든 코드 기반 접근 방식으로 사전 처리됨). 논리 파일에서 별도의 UI 파일을 사용하는 것은 항상 MVVM 패턴을 수용하는 데 권장되는 방법이었습니다. 그러므로 내가 주장하고 싶은 것은 Flutter가 비슷한 것을 가지고 있다는 것입니다. 인라인 UI DSL 형식 대신 Dart 코드와 별개로 자체 파일로 이동하도록 의도된 별도의 UI 형식이 있어야 합니다.

이러한 생각의 일환으로, 저는 지난 주말에 실제로 일부 작업을 완료했습니다. 잠시 시간을 할애할 수 있다면 "FLUI"라는 이름의 프로젝트를 개발했는데, 이는 그러한 형식이 어떻게 생겼는지 보여주려는 시도 입니다. 기존 DSL(또는 수정된 버전)을 사용하는 대신 YAML에서 영감을 얻은 완전히 새로운 DSL을 개발했으며 Flutter-constructor-approach 레이아웃의 "느낌"에 가깝게 유지하기 위해 최선을 다했습니다. 물론 _매우_ 초기 구현이므로 많은 문제가 없을 것으로 예상하지는 않지만 사람들이 플레이할 수 있도록 프로세서 스크립트(C#/.NET Standard로 작성)의 소스를 포함했습니다. 그들이 원한다면 그것으로. :)

React/RN과 Flutter 사용자로서 저는 "DSX"라는 아이디어에 크게 동의하지 않습니다.

DSX는 아무것도 가져오지 않을 것입니다. JSX는 JS 구문이 끔찍하기 때문에 반응에 사용됩니다. 그러나 Flutter의 경우 위젯 생성은 매우 쉽습니다.

클래식:

Widget build(BuildContext context) {
  return Center(
    child: Text("foo"),
  );
}

그것은 이미 즉시 사용할 수 있고, 쓰기 쉽고, 유형/일반 호환이 가능하고, 불필요한 중복이 없습니다.

현재 구문에 대해 가질 수 있는 유일한 불만은 "위젯의 닫는 괄호가 어디에 있는지 알기가 어렵습니다"입니다.

그러나 다시 공식적으로 지원되는 IDE의 dart 플러그인이 이 문제를 해결합니다. 따라서 vscode에서 이전의 코드를 열면 다음을 볼 수 있습니다.

Widget build(BuildContext context) {
  return Center(
    child: Text("foo"),
  ); // Center
}

"캐주얼 코드와 UI 코드를 구별하기 어렵다"는 반응 규칙이 flutter에도 적용됩니다.

위젯은 멍청하거나 똑똑해야 합니다. 스마트 위젯에는 UI 로직이 없습니다. 멍청한 위젯에는 UI 로직 외에는 아무것도 없습니다.

이 패턴을 따르면 UI를 나머지 부분과 구별하지 못하는 상황에 빠지지 않을 것입니다.
이것은 BLoC 패턴과 같은 것을 따를 때 더욱 사실입니다. 비즈니스와 UI의 분리를 강력하게 시행합니다.

JS 구문이 끔찍하기 때문에 JSX가 반응에 사용됩니다.

매우 독단적인 진술이며 사실이 아닙니다.

render() {
  return React.createElement(Container, { padding: EdgeInsets.all(20.0) },
    React.createElement(Text, { style: { color: Colors.black } },
      'foo'
    )
  );
}

Widget build(BuildContext context) {
  return Container(
    padding: EdgeInsets.all(20.0),
    child: Text(
      'foo',
      style: TextStyle(color: Colors.black)
    ),
  );
}

render() {
  return (
    <Container padding={EdgeInsets.all(20.0)}>
      <Text style={{ color: Colors.black }}>foo</Text>
    </Container>
  );
}

Widget build(BuildContext context) {
  return (
    <Container padding={EdgeInsets.all(20.0)}>
      <Text style={TextStyle(color: Colors.black)}>{'foo'}</Text>
    </Container>
  );
}

매우 독단적인 진술이며 사실이 아닙니다.

기본 반응 구문에는 불필요한 문자가 많이 있습니다.
각 문법(함수 정의, 들여쓰기, '반환' 제외)에 대한 단어 반복 및 문자 수를 비교해보자

JSX 없이 반응:

• 133자(괄호 3개, 대괄호 3개, : 3개, , 4개 및 공백 11개 포함)
• React.createElement 두 번 작성됨

JSX:

• 104자, 괄호 2개, 대괄호 3개, : 1개, <> 개, 공백 5개
• Container 및 Text 두 번 작성

다트:

• 99자, 괄호 2개, : 4개, , 3개, 공백 4개
• 반복 없음

문자 측면에서 명백한 승자는 다트 구문입니다.

이제 다른 다트 특성도 고려해야 합니다.

다트 유형은 단일 자식 대 다중 자식이며 const 생성자가 있으며 제네릭 및 위치 지정 매개변수도 허용합니다. JSX는 이들 중 어느 것도 지원하지 않습니다.

JSX로 잘못 변환되는 몇 가지 예:

항상 그런 것은 아님 children :

Scaffold(
  appBar: AppBar(),
  body: Container(),
)

OR

SingleChildScrollView(
  child: Container(
    height: 100.0,
  ),
)

const 위젯 자체의 생성자

const Padding(
  padding: const EdgeInsets.all(4.0),
)

제네릭

NotificationListener<ScrollNotification>(
  onNotification: (foo) {

  },
  child: child,
)

위치 소품:

Text("foo")

명명된 생성자

Positioned.fill(
  child: Container(),
);

빌더(dart는 공용체 유형을 지원하지 않으므로 children 는 위젯과 함수가 될 수 없음)

Builder(
  builder: (context) => Container(),
)

@rrousselGit

DSX는 이전에 여러 번 언급했듯이 단순히 다릅니다.
구문이며 Dart의 상위 집합이므로 할 수 있는 모든 것이
다트 DSX 내에서 할 수 있습니다. 둘 다 믹스 앤 매치 할 수도 있습니다
당신이 적합하다고 생각하는 구문. 분명히 당신은 확인을 귀찮게하지 않았습니다
지원하기 위해 수행된 DSX 기능 중 일부는
다트:
https://spark-heroku-dsx.herokuapp.com/index.html

-1---------------------------------------
다트에서:

Scaffold(
  appBar: AppBar(),
  body: Container(),
)

OR

SingleChildScrollView(
  child: Container(
    height: 100.0,
  ),
)

DSX에서:

<Scaffold
  appBar={<AppBar/>}
  body={<Container/>}
/>

OR

<SingleChildScrollView>
  <Container
    height={100.0}
  />
</SingleChildScrollView>

-2----------------------------------------------------
다트에서:

const Padding(
  padding: const EdgeInsets.all(4.0),
)

DSX에서:

const Padding(
  padding: const EdgeInsets.all(4.0),
)

-삼---------------------------------------
다트에서:

NotificationListener<ScrollNotification>(
  onNotification: (foo) {

  },
  child: child,
)

DSX에서:

<NotificationListener<ScrollNotification>
  onNotification={(foo) {

  }}
  child={child}
/>

-4 ---------------------------------------
다트에서:

Text("foo")

DSX에서:

<Text ["foo"]/>

-5--------------------------------------------------------
다트에서:

Positioned.fill(
  child: Container(),
);

DSX에서:

<Positioned.fill>
  <Container/>
</Positioned.fill>

-6---------------------------------------
다트에서:

Builder(
  builder: (context) => Container(),
)

DSX에서:

<Builder
  builder={(context) => <Container/>}
/>

그러나 반응에서 플러터로 더 쉽게 변환된다는 주장은 유효하지 않습니다. JSX는 프로토타입과 근본적으로 다르기 때문에:

<MyAppBar>
    <title:Text [] style={Theme.of(context).primaryTextTheme.title}>
        Example title
    </title:Text>
</MyAppBar>

그리고 여기 또는 링크에 있는 예제 중 어느 것도 실제로 코드를 단순화하거나 가독성을 향상시키지 않습니다.

JSX가 누락되었다는 느낌과 관련이 있을 수 있는 한(플러터를 시작할 때와 동일함) 약간의 경험 후에는 기본 구문이 실제로 꽤 좋게 느껴집니다.

참고로, 관심사 분리에 대한 훨씬 더 나은 솔루션이 있습니다. 템플릿 파일입니다
위젯 옆에 xml/yaml 파일이 있을 수 있습니다. 그런 다음 dart가 제공하는 멋진 코드 생성 도구를 사용하십시오.

나는 오히려 선호한다 :

// main.dart
import 'package:flutter/material.dart';

part 'main.g.dart';

class MyState extends StatefulWidget {
  <strong i="14">@override</strong>
  _MyStateState createState() => _MyStateState();
}

class _MyStateState extends State<MyState> {
  <strong i="15">@override</strong>
  Widget build(BuildContext context) {
    return $myStateStateTemplate(theme: Theme.of(context));
  }
}

와 결합

// main.xml
<strong i="19">@theme</strong> ThemeData

<Container  color={@theme.cardColor} />

그런 다음 사용자 정의 코드 생성을 사용하면 다음 다트 파일이 생성됩니다.

part of 'main.dart';

Widget $myStateStateTemplate({ThemeData theme}) {
  return Container(
    color: theme.cardColor,
  );
}

최종 결과는 UI/논리 분리를 위한 "DSX"보다 훨씬 낫습니다. 잠재적인 UI 생성기에도 더 좋습니다. 그리고 built 를 사용하여 구현하는 것이 훨씬 쉽습니다.

JSX는 프로토타입과 근본적으로 다르기 때문에:

정말로 !!! 이러한 논의에서 급진적이었던 유일한 것은 반대론자들의 반응이었습니다.

이 티켓의 제목에서 알 수 있듯이 DSX는 JSX와 유사하며 JSX와 동일하지 않습니다. 그렇지 않으면 JSX라고 불렸을 것입니다. 추가 사항은 미미하며 개발자에게 옵션을 제공합니다.

다음과 같이 작성할 수 있습니다.

<MyAppBar>
    <title:Text [] style={Theme.of(context).primaryTextTheme.title}>
        Example title
    </title:Text>
</MyAppBar>

or

<MyAppBar>
    <title:Text ['Example title'] style={Theme.of(context).primaryTextTheme.title}/>
</MyAppBar>

or

<MyAppBar
    title={<Text [] style={Theme.of(context).primaryTextTheme.title}>
        Example title
    <Text>}
/>

or

<MyAppBar
    title={<Text ['Example title'] style={Theme.of(context).primaryTextTheme.title}/>}
/>

흠 '관심의 분리'를 '기술의 분리'와 혼동하시는 것 같습니다. 이러한 것들은 매우 다릅니다. 다른 파일에서 dart 코드와 마크업 코드를 분리하는 것은 단순히 '기술 분리'이며 '관심 분리'의 ​​이점을 제공하지 않습니다. 여기서 우려되는 사항은 재사용 가능한 코드를 깔끔하게 캡슐화하는 구성 요소/위젯입니다. 해당 구성 요소/위젯 내부에서 다른 기술을 사용하는 것은 중요하지 않습니다.

또한 권장하는 대로 기술을 분리하는 것은 모든 명령형 구문(for 루프, 함수 호출, if 문 등)에 호스트 언어를 사용하는 JSX/DSX보다 훨씬 열등합니다.

여기에 많은 코드와 예제가 게시된 후( 특히 ), JSX가 DSX 및 Dart와 달리 JS에 훨씬 더 많은 가치를 추가한다는 결론에 도달했습니다. 그러나 한 가지 기능은 내 관점에서 매우 중요합니다. 바로 태그 닫기입니다. 좋다:

<SingleChildScrollView>
  <Container
    height={100.0}
  />
</SingleChildScrollView>

다음 과 대조적으로 다음과 같은 심층 구조에서 인지 복잡성을 많이 줄입니다.

SingleChildScrollView(
  child: Container(
    height: 100.0,
  ),
)

하지만 다음과 같이 사용하면 다음과 같습니다.

<Scaffold
  appBar={<AppBar/>}
  body={<Container/>}
/>

작은 이익이 있습니다.

이 티켓의 제목에 나와 있듯이 DSX는 JSX와 유사하며 JSX와 동일하지 않습니다.

내 "하지만 반응에서 플러터로의 변환이 더 쉽다는 주장은 유효하지 않습니다."를 놓쳤습니다.

DSX에 대한 주장의 절반은 "JSX는 반응에서 인기가 있습니다. 여기에서도 필요합니다."입니다. 그러나 JSX와 다른(그리고 더 복잡한) 것을 제안하고 있습니다.
나머지 절반은 UI를 코드에서 분리하는 것입니다. 템플릿 파일도 할 수 있습니다.

또한 권장하는 대로 기술을 분리하는 것은 모든 명령형 구문(for 루프, 함수 호출, if 문 등)에 호스트 언어를 사용하는 JSX/DSX보다 훨씬 열등합니다.

사실이 아니다. 템플릿 파일 내 if 및 기타 작업을 수행할 수 있습니다. cshtml 또는 각도 템플릿을 보십시오.

문제는 템플릿 파일입니다. 이미 파서가 있는 한 완전히 작동하는 일주일 이내에 flutter에 대해 구현할 수 있습니다.
지시문이 있는 yaml, xml, cshtml 또는 html입니다.

DSX에는 많은 작업이 필요합니다.

@Bessonov 그들은 최근에 닫기 태그를 조롱하기 위해 지원되는 IDE에 대한 가상 주석을 추가했습니다.

따라서 vscode에서 다음을 볼 수 있습니다.

SingleChildScrollView(
  child: Container(
    height: 100.0,
  ), // Container
) // SingleChildScrollView

태그 닫기의 이점. 입력하지 않고도

@rrousselGit

그들은 최근에 닫기 태그를 조롱하기 위해 지원되는 IDE에 가상 주석을 추가했습니다.

네, 인용 댓글에서 봤습니다. 하지만 같지 않습니다. 이것은 정렬 시프트를 도입하고 읽기 흐름을 방해합니다. 그리고 이것은 다른 IDE와 텍스트 프로세서에서는 도움이 되지 않습니다.

물건은 템플릿 파일입니다

IMHO 템플릿은 NIH 증후군을 앓고 있습니다. 저는 PHP와 HTML을 혼합하는 접근 방식이 올바른 방법이라고 말하지 않습니다. 그러나 반응은 JSX로 어떻게 더 잘 할 수 있는지 보여줍니다.

@rrousselGit

내 "하지만 반응에서 플러터로의 변환이 더 쉽다는 주장은 유효하지 않습니다."를 놓쳤습니다.

아니요, 댓글을 전혀 놓치지 않았습니다. JSX에서 온 사람들이 DSX를 너무 복잡하게 생각할 것이라고 말하는 것은 의미가 없습니다.

DSX에 대한 주장의 절반...

DSX를 선택하는 데는 여러 가지 이유가 있지만 대안이 있으면 사람들은 이유가 무엇이든 선호하는 것을 선택할 것입니다.

사실이 아니다. 당신은 당신의 템플릿 파일 내에서 if와 물건을 할 수 있습니다. cshtml 또는 각도 템플릿을 살펴보세요.

문제는 템플릿 파일입니다. 이미 파서가 있는 한 완전히 작동하는 일주일 이내에 flutter에 대해 구현할 수 있습니다.
지시문이 있는 yaml, xml, cshtml 또는 html입니다.

DSX에는 많은 작업이 필요합니다.

완전히 반대되는 DSX는 2개의 xml 변환만 구현하고 나머지는 호스팅 언어에서 무료로 얻습니다. 새로운 템플릿 언어 내에서 Dart의 기능을 다시 구현하려는 노력을 상상해 보십시오. 아니요, 다트를 가져가겠습니다.

아니요, 댓글을 전혀 놓치지 않았습니다. JSX에서 온 사람들이 DSX를 너무 복잡하게 생각할 것이라고 말하는 것은 의미가 없습니다.

현재 dart 구현에도 동일하게 적용됩니다.

어쨌든, 나는 우리가 여기서 서로를 설득할 수 없다고 생각합니다. 그래서 나는 왜 JSX를 플러터로 싫어하고 "기다려보고" 있는지에 대한 몇 가지 이유를 더 나열할 것입니다.

1. 위젯 생성은 React와 다릅니다.

반응에서 구성 요소 생성을 처리하는 것은 라이브러리입니다. JSX는 "일이 어떻게 돌아가는지 신경쓰지 마세요. 우리는 당신을 위해 일을 합니다"라고 말하기 때문에 괜찮습니다.

플러터에서는 그렇지 않습니다. 빌드 호출 시마다 새 위젯을 수동으로 인스턴스화합니다. 이것은 이해하는 것이 정말 중요하며 JSX는 이를 덜 명확하게 만듭니다.

그리고 그 논리의 연속에서 :

2. 사람들은 <Foo /> 이 new Foo() 가 하지 않는 특별한 일을 한다고 생각할 수 있습니다.

메소드의 <Foo /> 는 특별하게 느껴집니다. 프레임워크에 내장된 관련 없는 작업을 수행하는 것 같습니다. 구성 요소가 React.Element 로 래핑된 반응에서는 사실입니다.
이것은 반응에서 <Foo /> != new Foo() 로 변환되며 Foo 에 직접 액세스할 수 없습니다.

이것은 플러터에 적용되지 않으며 혼란을 일으킬 수 있습니다.

또한 :

<Foo>
  <Bar />
</Foo>

반응에서 Foo 가 자식을 사용하지 않으면 $ Bar 가 인스턴스화되지 않습니다. 그리고 $# render 메서드가 반환된 후 Foo 가 인스턴스화됩니다.
플러터에서는 그 반대입니다. Bar 및 Foo 모두 즉시 생성됩니다.

이것은 잠재적으로 React 개발자가 최적화되지 않은 플러터 코드를 만들 수 있습니다.

3. 일반적으로 Dart/flutter는 JS/react가 아닙니다.

다트에 JSX를 추가하면 이미 유형 통합에 대한 문제를 볼 수 있거나 할 수 있습니다.
return foo && <Component /> 또는 반응의 다가오는 비동기 렌더링.
"우리는 이미 JSX를 가지고 있으므로 그것을 가질 수 있습니다!"로 정당화됩니다.

dart에서 최신 JSX/react 기능을 구현할 필요가 없도록 독점적인 구문을 사용하거나 구문을 사용하지 않는 것을 선호합니다.

4. JSX는 일부 다트 세부 사항을 불분명하게 만듭니다.

작은 예인 Scaffold 에는 appbar a PrefferedSizeWidget 가 필요합니다.
JSX를 사용하여 Scaffold 를 만들었다면 사람들은 주어진 JSX를 다른 JSX로 바꿀 수 있을 거라고 예상할 것입니다. 사실이 아닌 것

내 말은, 그것은 우리가 왜 할 수 있는지 매우 불분명하게 만듭니다

<Scaffold
  appbar={<AppBar />}
/>

하지만

<Scaffold
  appbar={<Container />}
/>

@rrousselGit

어쨌든, 나는 우리가 여기서 서로를 설득할 수 없다고 생각합니다. 그래서 나는 왜 JSX를 플러터로 싫어하고 "기다려보고" 있는지에 대한 몇 가지 이유를 더 나열할 것입니다.

나는 당신이 말한 많은 부분에 동의하지 않지만, 당신이 이 문제에 대해 깊이 생각하는 데 시간을 할애해 주셔서 감사합니다.

1. 위젯 생성은 React와 다릅니다.

나에게 이것은 구현 세부 사항이기 때문에 중요하지 않습니다. 개념적으로 XML을 보면 React에서는 구성 요소이고 Flutter에서는 위젯입니다.

1. 사람들은 생각할 수 있습니다 new Foo()가 하지 않는 특별한 일을 합니다.

나는 사람들이 Dart/DSX가 Javascript/JSX가 아니라는 것을 꽤 빨리 배울 것이라고 생각합니다.

1. 일반적으로 Dart/flutter는 JS/react가 아닙니다.

예, 마침내 우리는 무언가에 동의하지만 그것들이 서로 다르지만 공통 스레드는 선언적 UI 프레임워크이고 선언적 트리 구조가 JSX/DSX에서 잘 처리된다고 생각합니다. 선언적 프로그래밍 사고 방식을 유지합니다.

dart에 JSX를 추가하면 이미 type union에 대한 문제를 볼 수 있거나 반응에서 return foo && <Component /> 또는 다가오는 비동기 렌더링을 수행할 수 있습니다.
"우리는 이미 JSX를 가지고 있으므로 그것을 가질 수 있습니다!"로 정당화됩니다.

우리는 Dart에 JSX를 추가하는 것이 아니라 DSX를 추가하고 있습니다. 이것은 다르지만 JSX와 유사하고 친숙함이 큰 것입니다.

나는 dart에서 최신 JSX/react 기능을 구현할 필요가 없기 때문에 독점 구문을 사용하거나 구문을 사용하지 않는 것을 선호합니다.

그렇다면 왜 Dart를 사용하고 있습니까? Java와 매우 유사해 보이지만 Java와는 다릅니다. 젠장, 이 모든 Java 키워드와 개념을 스크랩하고 에베레스트 산 꼭대기에서 프레첼 요가 동작을 하면서 한 손으로만 프로그래밍할 수 있는 Erland와 막연하게 유사한 것을 생각해 봅시다 ;)

1. JSX는 일부 다트 세부 사항을 불분명하게 만듭니다.

실제로는 그렇지 않습니다. 비교할 수 없는 위젯을 연결하면 Dart 컴파일러는 일반 Dart에서 수행한 것처럼 오류 메시지를 표시합니다. 나는 DSX가 단순히 얇은 구문 설탕이라는 것을 충분히 강조할 수 없습니다. 마법은 없으며 동일한 것에 대한 구문의 차이일 뿐입니다.

@cbazza 귀하의 게시물을 읽는 데 몇 시간을 보냈으며 이 문제에 대한 귀하의 노력에 정말 감사드립니다. 그러나 나는 논쟁을 끝내는 것이 (일종의) 쉽다고 생각한다. 플럭스가 react의 공식 상태 관리 솔루션이었지만 지금은 모두가 redux를 사용하고 있다는 것을 기억하십니까? 반응 네이티브를 위한 탐색 라이브러리는 몇 개입니까? DSX 저장소를 만들고 반응 개발자가 뛰어들게 하십시오.

@rrousselGit

이전에 Dart에서 part / part of 구문을 본 적이 없으며 이에 대한 문서를 찾는 데 문제가 있습니다. Dart/Flutter가 공식적으로 지원하는 것입니까? FLUI에서 그런 것을 사용하고 싶습니다.

@cbazza

당신은 DSX 정당성을 가지고 계속 원을 그리며 돌아다닙니다. DSX는 JSX가 아닙니다. DSX는 JSX와 유사합니다. DSX는 React 개발자에게 친숙한 구문입니다. DSX는 Dart를 위한 단순한 생각 구문 설탕입니다. 사람들은 DSX가 JSX가 아니라는 것을 알게 될 것입니다. (등등.)

그 모든 설명으로 당신이 하려는 요점은 이해하지만, 계속 만들어야 한다는 사실은 일반적으로 DSX의 특성에 관한 주요 문제를 드러내고 rrouselGit도 제기한 요점이라고 생각합니다. DSX가 JSX가 _아닙니다_라고 계속 말씀하시더라도 그것을 찾는 사람들은 그것이 문제라고 생각할 것입니다. JSX와 JSX를 사용하는 사람들은 기본 수준에서 Dart/Flutter와 개념적으로 매우 다른 생태계에서 왔습니다. 따라서 "익숙함"을 위한 기능을 개발하는 것이 반드시 좋은 것은 아닙니다. 이와 같은 더 분명한 이유 중 하나는 지적한 바와 같이 사람들이 다음과 같은 것을 시도할 것이기 때문입니다.

Widget build(BuildContext context) {
    return isDialogVisible && <Widget>...</Widget>;
}

Javascript/JSX에서 가져왔기 때문에 해당 구문이 DSX에서 작동할 것으로 기대합니다. 그렇지 않으면 인지 부조화의 지점이 되어 실제로 DSX뿐만 아니라 Flutter 전체에 대한 관심을 _상처_할 수 있습니다. 친숙함은 사람들을 새로운 것에 쉽게 몰입하게 하는 수단으로 사용될 때 유익하지만 그것은 양날의 검이 될 수 있습니다. 기능의 90%가 동일할 때 나머지 10%는 단지 좌절감과 성가심으로 작용할 수 있습니다.

DSX의 또 다른 문제는 그것이 제3자 플러그인인지 또는 Flutter에서 공식적으로 채택하는지에 관계없이 곧 원활하게 통합되는 기능이 아닐 가능성이 있다는 것입니다. 스스로 말했듯이 Flutter 디버깅 및 배포 프로세스와 진정으로 작동하려면 Flutter 팀뿐만 아니라 Dart 팀의 공식 지원이 필요합니다. 사전 처리 및 도구 지원 없이 DSX가 작동하는 유일한 방법은 외부 수동 ​​변환 도구를 사용하는 것입니다. 이는 개발자가 거쳐야 하는 또 다른 (잠재적으로 긴) 단계일 뿐입니다.

이것을 입력하는 동안 나에게 일어난 또 다른 일이 있습니다. 이 스레드에는 UI 디자인에 대한 "관심 분리" 접근 방식이 UI 개발을 다시 고려하게 될 유일한 방법이라고 JSX를 칭찬한 여러 친 JSX 사람들이 있었습니다. 그렇다면 왜 React가 그것을 사용하는 시장에서 유일한 프레임워크입니까? 네이티브 및 크로스 플랫폼 모바일 앱 프레임워크는 모두 스토리보드, XML 파일, XAML 파일 및 기타 UI 정의 DST를 고수하고 있습니다. Angular 및 떠오르는 Vue와 같은 다른 인기 있는 JS 프레임워크조차도 여전히 "기술 분리" 접근 방식을 사용합니다. React 개발자들은 JSX가 미래의 방식인 것처럼 말하지만 실제 견인력을 얻은 프레임워크에서 React 이외의 다른 곳에서는 아직 나타나지 않았습니다.

@andrewackerman

part / part of 는 기존 다트 기능입니다. 어떻게 든 두 개의 파일을 하나로 결합합니다. 일반적으로 코드 생성에 사용됩니다.

이러한 기술을 사용하는 몇 가지 실제 사례 시나리오가 있습니다. toJSON 메서드와 속성을 기반으로 클래스에 대한 fromJSON 팩토리를 생성하는 $#$ json_serializable $#$와 같습니다.

part / part of 혼자서는 아무 것도 하지 않습니다. 흥미로운 부분은 이것을 source_gen 과 같은 것과 결합할 때입니다.

@sunnylqm

현재 문제는 .dsx 파일에서 작업하는 디버거, 자동 완성 등으로 훌륭한 개발자 경험을 제공하기 위해 DSX를 Flutter 도구와 적절하게 통합하는 것에 관한 것이기 때문에 repo에 코드를 넣는 것이 내 문제를 해결할 것이라고 생각하지 않습니다.

사용자에게 DSX를 사용할 수 있지만 디버거를 사용할 수 없거나 자동 완성 기능을 사용할 수 없다고 말하는 것은 저에게는 시작하기 어려운 일입니다. 누군가 도와주고 싶다면 내가 필요한 것은 Dart Tools 및 VS Code Dart 플러그인에 완전한 전처리 지원(소스 맵 포함)을 추가하는 방법을 찾는 것입니다. 일단 도구가 해당 DSX 또는 다른 트랜스파일링 언어(모든 언어 Dart의 상위 집합이지만 모든 것을 Dart까지 컴파일함)이 작동합니다.

@andrewackerman

나는 아무 것도 정당화할 필요가 없습니다. 저는 DSX가 히트할 것이라고 매우 확신하며 이 티켓에만 거의 100명의 사람들이 관심을 가지고 있습니다.

사전 처리 및 도구 지원 없이 DSX가 작동하는 유일한 방법은 외부 수동 ​​변환 도구를 사용하는 것입니다. 이는 개발자가 거쳐야 하는 또 다른 (잠재적으로 긴) 단계일 뿐입니다.

DSX 변환기는 눈부시게 빠르며 .dsx 파일을 깜박이는 것보다 빠르게 .dart 파일로 변환할 수 있으므로 속도는 문제가 되지 않습니다. 사람들이 DSX를 사용하는 것을 간단하게 만들기 위해 기능 패리티를 얻으려고 합니다.

그렇다면 왜 React가 그것을 사용하는 시장에서 유일한 프레임워크입니까? 네이티브 및 크로스 플랫폼 모바일 앱 프레임워크는 모두 스토리보드, XML 파일, XAML 파일 및 기타 UI 정의 DST를 고수하고 있습니다.

타임라인을 만들기만 하면 UI 개발의 진화를 볼 수 있습니다. 현재 방식으로 Android 및 iOS 개발이 시작된 지 10년이 넘었으므로 10년 된 기술(완전히 명령적인 기술)을 사용합니다. Reactive UI 개발(선언적) 기술은 약 8년 전에 웹에 등장하기 시작했습니다. React는 5년 전에 등장했으며 JSX와 기술을 매끄럽게 결합한 최초의 Reactive 프레임워크였습니다. Vue는 이제 이전의 '기술 분리' 기술을 지원하지만 JSX도 지원하는 최신 Reactive 프레임워크입니다. 모바일에서 Flutter는 최신 버전이며 React로 Reactive 프레임워크 기술을 사용하며 Vue가 JSX를 활용하는 것처럼 DSX도 활용할 수 있습니다. Vue는 개발자에게 선택권을 제공하고 지나치게 독단적이지 않기 때문에 Angular를 죽이고 있습니다.

별도의 템플릿 파일의 문제는 거기에 있는 명령형 프로그래밍 구성(if, for 루프 등)이 비즈니스 논리에 사용되는 프로그래밍 언어에서 사용할 수 있는 것에 비해 너무 약하다는 것입니다. JSX가 하는 방식으로 2를 결합하는 것은 분명히 미래입니다.

React 개발자는 JSX가 미래의 길인 것처럼 이야기합니다.

그것은 !!!

그러나 실제 견인력을 얻은 프레임워크에서 React 이외의 다른 곳에서 팝업이 표시되는 것을 아직 보지 못했습니다.

Vue는 JSX를 사용합니다.

@cbazza

나는 아무 것도 정당화할 필요가 없습니다. 저는 DSX가 히트할 것이라고 매우 확신하며 이 티켓에만 거의 100명의 사람들이 관심을 가지고 있습니다.

나는 당신이 무엇이든 정당화할 필요가 _해야_ 한다고 말하는 것이 아닙니다. Flutter 팀이 이 제안을 선택하고 스스로 구현해야 한다고 주장했을 때, 네, 충분히 정당화할 수 있다고 말했을 것입니다. 이제 당신이 스스로 하려고 하고 있으므로, 당신이 생각하기에 충분하다고 생각하는 정당화와 당신에게 더 많은 힘을 위해 당신이 원하는 것은 무엇이든 할 수 있습니다. 나는 그것이 당신이 생각하는 것만큼 쉽거나 인기가 없을 수 있다고 생각하는 이유를 말할 뿐입니다. 그리고 나는 그들을 무시하기 위해 당신의 코트에 공을 두고 있습니다.

DSX 변환기는 눈부시게 빠르며 .dsx 파일을 깜박이는 것보다 빠르게 .dart 파일로 변환할 수 있으므로 속도는 문제가 되지 않습니다. 사람들이 DSX를 사용하는 것을 간단하게 만들기 위해 기능 패리티를 얻으려고 합니다.

지금까지 크기가 작은 UI 및 앱에서 테스트했다고 가정합니다. 중요하지 않은 것은 어떻습니까? 엣지 케이스에 속하는 것들은 어떻게 됩니까? 또한 프로세스에 소요되는 실제 시간이 유일한 관련 부분은 아닙니다. 개발자가 빌드하기 전에 수동 작업의 또 다른 체크리스트를 거쳐야 한다는 사실만으로도 많은 사람들이 꺼리기에 충분합니다.

또한 아직 프로젝트의 소스 코드를 실제로 공개하지 않았기 때문에 아무도 당신의 프로세스를 살펴보고 발견한 내용을 다시 확인하고 개선 사항을 제안할 수 없었습니다. 이 시점에서 누구나 할 수 있는 일은 편리하고 성능이 좋다는 말에 동의하는 것뿐입니다.

Vue는 JSX를 사용합니다.

저는 Vue를 거의 1년 가까이 사용해 왔으며 그 동안 다양한 작업이 수행되는 방식을 보기 위해 많은 오픈 소스 프로젝트 저장소를 살펴보았습니다. 나는 스스로를 Vue 마스터라고 생각하지 않지만, 내가 말하고자 하는 것은 그들 중 단 한 곳에서도 JSX가 실제로 활용되는 것을 본 적이 없다는 것입니다. 사람들은 .vue 접근 방식을 엄청나게 선호하는 것 같습니다(템플릿 -script-styling) 렌더+JSX 접근 방식보다. 나는 Vue가 Vue 문서를 조사하고 렌더링 기능 섹션 에서 이에 대한 작은 정보 조각을 발견할 때까지 Vue가 JSX(적어도 babel 플러그인을 통해)를 지원한다는 사실조차 몰랐습니다.

그러나 이것은 나의 전반적인 요점과 관련이 없습니다. Vue는 여전히 Javascript 프레임워크입니다. Flutter는 확실히 그렇지 않습니다. 따라서 Dart+Flutter로 변환되지 않는 Javascript 중심 환경에서 JSX를 가장 최신의 것으로 만드는 데에는 많은 이유가 있습니다. 그 중 많은 부분이 이 스레드에서 이미 다뤘습니다.

그것은 !!!

자바스크립트가 아닌 개발 환경에서 그것이 인기를 얻는 것을 볼 때까지 나는 정중하게 동의하지 않을 것입니다.

Vue는 JSX를 사용합니다.

Vue 지정은 다양한 용도로 사용됩니다. JSX는 "거기"에 있습니다. 그러나 지배적인 구문은 아닙니다.
원한다면 JSX를 Angular에 연결할 수 있습니다. 아무도 하지 않지만

React 개발자는 JSX가 미래의 길인 것처럼 이야기합니다.
그것은 !!!

미래의 큰 후보는 웹 구성 요소입니다. 그리고 Angular 또는 Vue의 가장 일반적인 형식에서 찾을 수 있는 것과 유사한 html에서 직접 사용됩니다.

@andrewackerman

개발자가 빌드하기 전에 직접 조치에 대한 또 다른 체크리스트를 거쳐야 한다는 사실만으로도 많은 사람들이 꺼려합니다.

누가 직접 조치에 대해 뭐라고 했습니까? 나는 완전한 IDE 통합(개발자를 위한 최상의 사용자 경험)을 얻으려고 노력하고 있음을 분명히 하지 않았습니까?

또한 아직 프로젝트의 소스 코드를 실제로 공개하지 않았기 때문에 아무도 당신의 프로세스를 살펴보고 발견한 내용을 다시 확인하고 개선 사항을 제안할 수 없었습니다.

그것이 DSX를 사용하는 사람들과 어떤 관련이 있습니까? 저는 2년 넘게 JSX를 사용해 왔으며 소스 코드에 대해 그다지 신경을 쓰지 않았습니다. Dart에서 프로그래밍하려면 Dart 컴파일러의 소스 코드를 봐야 합니까?

내가 말하려는 것은 그들 중 단 한 곳에서도 JSX가 실제로 활용되는 것을 본 적이 없다는 것입니다. 사람들은 렌더+JSX 접근 방식보다 .vue 접근 방식(템플릿 스크립트 스타일 지정)을 훨씬 더 선호하는 것 같습니다.

JSX는 새로 추가된 것이므로 퍼뜨리는 데 시간이 걸리겠지만 중요한 점은 Vue에서 개발자가 Vue에서 수행해야 하는 '올바른 방법과 유일한 방법'을 사용하도록 강요하지 않고 다른 접근 방식을 수용한다는 것입니다.

Vue는 여전히 Javascript 프레임워크입니다. Flutter는 확실히 그렇지 않습니다.

따라서 JSX 대신 Flutter와 함께 DSX를 사용합니다.

@rrousselGit

미래의 큰 후보는 웹 구성 요소입니다.

웹 구성 요소는 죽었지만 여전히 걷고 있는 동물원입니다. 그들은 캐나다에서 캥거루만큼 널리 퍼져 있습니다. 나는 며칠 동안 계속할 수 있지만 탈선을 피하기 위해 ...
https://dmitriid.com/blog/2017/03/the-broken-promise-of-web-components/

@cbazza

누가 직접 조치에 대해 뭐라고 했습니까? 나는 완전한 IDE 통합(개발자를 위한 최상의 사용자 경험)을 얻으려고 노력하고 있음을 분명히 하지 않았습니까?

또한 이를 위해서는 Flutter/Dart 팀의 전처리 지원이 필요하다고 말씀하셨습니다. 내가 잘못 알고 있습니까?

그것이 DSX를 사용하는 사람들과 어떤 관련이 있습니까? 저는 2년 넘게 JSX를 사용해 왔으며 소스 코드에 대해 그다지 신경을 쓰지 않았습니다.

JSX는 Facebook에서 React용으로 개발했으며 엄격한 제안/설계/구현/반복 프로세스를 거친 후 손에 들어가기 몇 년 전에 세상에 출시되었습니다. 실제 환경에서 엄격하게 테스트되고 반복적으로 입증되었습니다. 성숙한 기술입니다. 그런 것에 대한 사양 시트를 볼 것을 요구할 이유가 없습니다.

반면에 DSX는 오늘날 당신과 소수의 사람들에 의해 개발되고 있습니다. 당신은 그것이 무엇을 할 수 있고 무엇을 할 수 있을지에 대해 설득력 있게 설명했지만 실제로 우리가 _본_ 것은 소수의 특수 목적 코드 스니펫과 그것들이 트랜스파일러에 의해 생성되었다는 귀하의 말뿐입니다. 그것을 시도하고 가능한 변경이나 개선 사항을 제안하고 싶어하는 사람들은 그렇게 할 수 없으므로 "Yay JSX!" 이상의 노력을 지원할 이유가 없습니다.

나는 당신이 거짓말을 하거나 다른 것을 비난하는 것이 아니라 단지 JSX가 DSX가 가지지 못한 수준의 믿음을 얻었다고 말하는 것뿐입니다. 그래서 사람들이 그것을 만지작거리게 하지 않는다면 어떻게 고개를 돌릴 것입니까?

JSX는 새로 추가된 것이므로 퍼뜨리는 데 시간이 걸리겠지만 중요한 점은 Vue에서 개발자가 Vue에서 수행해야 하는 '올바른 방법과 유일한 방법'을 사용하도록 강요하지 않고 다른 접근 방식을 수용한다는 것입니다.

JSX는 거의 2년 동안 Vue에 있었습니다. Vue 자체와 달리 JSX는 특히 React에 익숙한 사람들에게 소개가 필요 없는 기존 기술입니다. JSX가 Vue.js 세계를 폭풍으로 몰아넣을 예정이라면 지금쯤이면 그렇게 했을 것이라고 생각하지 않을 수 없습니다. (특히 당신이 주장하는 것처럼 많은 사람들이 Flutter에서 JSX를 요구하고 있다는 징후라면 더욱 그렇습니다.)

따라서 JSX 대신 Flutter와 함께 DSX를 사용합니다.

JSX와 DSX는 동일한 구문 개념입니다. 문제는 JSX가 JavaScript와 같은 약한 유형의 동적 언어에 구축된 반면 DSX는 Dart와 같은 강력한 유형의 정적 언어에 구축된다는 것입니다. 즉, 틈새 "JSX for Flutter" 구현이 아닌 다른 어떤 것이든 JSX가 처리할 필요가 없다는 점을 DSX가 설명해야 하는 많은 문제가 있으며 DSX가 실제로 작동하려면 몇 가지 _독창적인_ 수정이 필요합니다. 시각적으로 더 간결하다는 주장을 정당화하기에는 너무 부풀려지지 않습니다.

그리고 "DSX는 단지 Dart입니다. DSX가 뭔가를 할 수 없다면 Dart를 사용하십시오"라는 반박을 다루기 위해 DSX가 하지 않는 시나리오에 직면할 때마다 Dart로 계속 돌아가야 하는 경우가 있습니다. 그렇다면 왜 항상 Dart를 사용하면 안 될까요?

그리고 "원한다면 할 수 있습니다. DSX는 하나의 옵션일 뿐입니다"라는 반론 을 다루기 위해, 당신은 정말로 자신을 과소평가하고 있는 것입니다. 그것이 정말로 "옵션"이 되더라도 사람들이 그것을 사용하도록 설득할 무언가를 테이블에 가져와야 합니다. DSX는 JSX가 아니므로 JSX만 원하는 사람들은 원하는 것을 얻지 못할 것이라고 스스로 말씀하셨습니다. 그것은 사람들이 그것을 사용하고 싶어하는 "JSX와 같은 매력"을 넘어서 몇 가지 확실한 이유가 필요하다는 것을 의미합니다.

자신이 사용하고 싶은 도구를 구축하는 중이라면 이 모든 것이 무의미해지고 미쳐버릴 수 있습니다. 그러나 다른 사람들이 사용하도록 의도한 것을 실제로 구축하고 있다면, 왜 그들이 그래야 한다고 생각하는지 확고한 형식으로 넣어야 합니다.

웹 구성 요소는 죽었지만 여전히 걷고 있는 동물원입니다. 그들은 캐나다에서 캥거루만큼 널리 퍼져 있습니다. 나는 며칠 동안 계속할 수 있지만 탈선을 피하기 위해 ...

다소 주제에서 벗어나지만 웹 구성 요소에 대한 지원이 tar보다 느리게 추가되더라도 웹 구성 요소는 미래에 대한 유망한 모습이라는 점을 지적하고 싶습니다. 이렇게 생각해 보세요. React는 기본적으로 Javascript 전용 웹 구성 요소 아이디어를 구현하기 때문에 수행하는 작업을 수행합니다. 이러한 기능이 브라우저에서 지원되고 샌드박싱되지 않은 성능의 이점을 누리고 DOM 조작을 통해 작동하지 않아도 된다면 얼마나 더 좋을지 상상해 보십시오. (알기까지 20년은 더 걸릴 수도 있지만 여전히...)

@andrewackerman

미안 친구야 나는 끝없이 논쟁하고 내가 전에 말한 것을 계속해서 반복할 시간이 없다. 어쨌든 우리는 합의로 끝나지 않을 것이므로 귀하의 FLUI에 행운을 빕니다.

당신은 그것이 무엇을 할 수 있고 무엇을 할 수 있을지에 대해 설득력 있게 설명했지만, 우리가 실제로 본 것은 소수의 특수 목적 코드 스니펫과 트랜스파일러에 의해 생성되었다는 귀하의 말씀뿐입니다.

온라인 DSX 트랜스파일러는 2018년 2월부터 사용 중이며 누구나 사용할 수 있으므로 내 말을 따를 필요가 없습니다. '컴파일'을 누르면 왼쪽 패널에 작성된 내용을 컴파일하고 오른쪽 패널에 결과를 배치합니다. 디버거를 열면 AST가 작성된 것을 볼 수 있습니다.
https://spark-heroku-dsx.herokuapp.com/index.html

문제는 JSX가 JavaScript와 같은 약한 유형의 동적 언어에 구축된 반면 DSX는 Dart와 같은 강력한 유형의 정적 언어에 구축된다는 것입니다.

OOP(객체 지향 프로그래밍) 개념 및 '클래스' 구문과 같이 큰 차이는 없습니다. 유형이 없는 Javascript 또는 유형이 지정된 Dart에서 거의 동일합니다. 'if' 문, 'for' 문 등에 대해서도 마찬가지입니다.

여전히 사람들이 그것을 사용하도록 설득할 무언가를 테이블에 가져와야 합니다.

분명히 이 티켓의 100명에게 이미 적용됩니다. 그리고 그것은 내가 그것을 사용하는 것보다 100배 더 큽니다. 나에게 충분히 좋다.

@cbazza

미안 친구야 나는 끝없이 논쟁하고 내가 전에 말한 것을 계속해서 반복할 시간이 없다. 어쨌든 우리는 합의로 끝나지 않을 것이므로 귀하의 FLUI에 행운을 빕니다.

나는 단지 논쟁을 위해 또는 뿌리깊은 반 JSX 편견 때문에 당신과 논쟁하는 것이 아닙니다. 나는 당신이 대답해야 할 질문에 대답하도록 하려고 합니다. 당신은 아마도 다른 사람들이 사용하도록 의도한 도구를 개발하고 있지만 여전히 "익숙함"과 "더 좋기 때문에"라는 모호하고 주관적인 이점을 넘어서 사용해야 하는 설득력 있는 이유를 제시하지 않았습니다. 앞서 말했듯이 전자가 반드시 좋은 것은 아니며 후자는 아직까지 실질적인 근거가 없는 주장입니다.

당신의 도구가 성공하기를 바란다면 당신이 하는 일과 그 일을 하는 이유를 명확히 해야 하고, 다른 사람들에게 쉽게 전달할 수 있는 방식으로 해야 합니다. _모두가 좋아할 때까지 제품을 만들 수 없다는 말은 아니지만 명확하고 간결한 목표는 디자인 및 구현을 형성하는 데 중요합니다. 그렇지 않으면 기껏해야 틈새 제품이 될 방향 없는 유틸리티로 끝날 것이고 그것이 어떤 규모의 프로덕션 코드로 끝날 경우 매우 운이 좋을 것입니다.

온라인 DSX 트랜스파일러는 2018년 2월부터 사용 중이며 누구나 사용할 수 있으므로 내 말을 따를 필요가 없습니다. '컴파일'을 누르면 왼쪽 패널에 작성된 내용을 컴파일하고 오른쪽 패널에 결과를 배치합니다. 디버거를 열면 AST가 작성된 것을 볼 수 있습니다.

나는 그 링크가 실제 사례라는 것을 보지도 못했습니다. 나는 전에 herokuapp을 사용한 적이 없으며 그것은 단지 요지와 같은 것처럼 보였으므로 그것은 나에게 달려 있습니다. :피

(온라인 샌드박스를 수정하는 것이 보다 실용적인 환경에서 트랜스파일러를 테스트하는 것과 같지 않음을 지적하겠습니다.)

OOP(객체 지향 프로그래밍) 개념 및 '클래스' 구문과 같이 큰 차이는 없습니다. 유형이 없는 Javascript 또는 유형이 지정된 Dart에서 거의 동일합니다. 'if' 문, 'for' 문 등에 대해서도 마찬가지입니다.

당신은 이미 child strong-typing 에서 이러한 차이점을 다루어야 했습니다. 속성 강형은 어떻습니까? 같은 이름을 가진 다른 라이브러리의 위젯은 어떻습니까? 누군가가 두 개 이상의 이름 없는 위치 인수로 위젯을 만들면 어떻게 될까요? 같은 이름의 위젯이 있는 두 개의 라이브러리를 가져오면 어떻게 됩니까? Javascript와 Dart와 같은 시스템 간의 고유한 차이점을 추가로 보여주기 위해 팝업으로 생각하지 않은 일부 시나리오에서 어떤 일이 발생합니까? 이 토론 포인트에 대해 너무 경솔한 태도를 보여 실제 환경에서 DSX의 수명에 대해 걱정하게 만듭니다.

분명히 이 티켓의 100명에게 이미 적용됩니다. 그리고 그것은 내가 그것을 사용하는 것보다 100배 더 큽니다. 나에게 충분히 좋다.

다시 말하지만, "다트 코드 내에서 JSX와 유사한 구문을 고려하십시오"를 기반으로 이 문제에 찬성표를 던진 사람은 100명입니다. 그들은 _JSX_를 원하기 때문에 찬성했습니다. 그리고 당신이 지적하고 싶어했던 것처럼 DSX는 JSX가 아닙니다. 그렇다면 왜 그들이 DSX를 사용하기를 원할까요? 인라인 XML과 같은 UI 선언이 "미래"이기 때문에? 다시 말하지만, 나는 그것을 보지 못한다.

우리는 이미 Vue에서 JSX를 다루지 않고 있지만 링크한 Web Components 기사에서 언급한 두 가지 React 대안인 Inferno와 Preact도 있습니다. 내가 말할 수 있는 한, 둘 다 기본적으로 JSX와 같은 구문을 지원함에도 불구하고 JS 기반 웹 앱 개발 세계에서 어떤 종류의 파도도 만들지 못했습니다. 나는 정말로 사람들이 React에서 JSX를 좋아하는 _정확히 이유_에 대해 길고 열심히 살펴볼 필요가 있다고 생각합니다. 모든 계정에서 JSX 자체 때문이 아닌 것 같기 때문입니다. _그_ 질문에 답할 수 있다면, 우리는 우리가 개인적으로 생각하는 다른 모든 곳에서 우리가 좋아했던 한 라이브러리의 기능을 프랑켄슈타인하는 것보다 "미래" 혁신을 향해 나아갈 수 있습니다.

이 토론에 투자한 에너지의 양과 현재 프레임워크를 개선하기 위해 무엇을 할 수 있었는지 생각하면 오히려 안타깝습니다.

@andrewackerman

문제는 JSX가 JavaScript와 같은 약한 유형의 동적 언어에 구축된 반면 DSX는 Dart와 같은 강력한 유형의 정적 언어에 구축된다는 것입니다.

죄송하지만 이것은 문제가 되지 않습니다. 게다가 이것은 전혀 의미가 없습니다. 그 외에도 TypeScript와 함께 JSX를 사용합니다.

@escamoteur 절대적으로!

@escamoteur 이 문제에 대해 함께하겠습니다. _100._

@베소노프

죄송하지만 이것은 문제가 되지 않습니다. 게다가 이것은 전혀 의미가 없습니다. 그 외에도 TypeScript와 함께 JSX를 사용합니다.

React는 TypeScript용으로 설계되지 않았습니다. 자바스크립트용으로 설계되었습니다. 모든 위젯 정의, 속성, 속성 및 기타 모든 것은 JavaScript의 동적 환경에서 사용하도록 설계되었으므로 TypeScript의 유형 안전성은 JSX가 React와 상호 작용하는 방식에 새로운 요소를 도입하지 않습니다. 이것은 JSX가 Flutter와 완전히 다른 설정을 위해 어떻게 설계되었는지에 대한 또 다른 예입니다.

@andrewackerman
그것이 왜 중요하다고 생각합니까? JSX는 인터페이스를 설명하는 방법입니다. 그 자체로 언어 불가지론입니다. 여기 봐 . 자바스크립트가 아닙니다. 하지만 왜 JSX로 할 수 없습니까? (게다가 (아직) 구현되지 않음)

그리고.. 아시다시피... 흐름도 fb에서 나옵니다.

Flow는 JavaScript용 정적 유형 검사기입니다.

한 번도 사용하지 않은 확장 프로그램에 대한 찬반 논쟁을 중단하십시오. 나는 JSX를 매일 사용하고 ATM에 만족하지만 그것에 대해 매우 회의적입니다. JSX가 AngularJS와 마찬가지로 다른 패턴으로 발전한다고 상상할 수 있습니다.

그리고 이 주제가 더 나은 Dart 패턴을 찾는 데 도움이 될까요? DSX는 하나의 제안일 뿐입니다. 위의 빌더 패턴 예제 또는 여기에 제시된 다른 언어 조정을 보십시오. 그리고, 아마도 독감 이 더 나은 방법일까요? 모르겠어요. 하지만 남의 제안에서 안 좋은 점을 논하기 보다는 그것을 찾아 서로의 제안을 개선할 수 있도록 도웁시다.

나는 이 주제를 닫고 제한된 대화로 새로운 우산 주제를 열 것을 제안하고 싶습니다. 방법을 개선하기 위한 모든 제안, flutter 사용 방법, 사랑과 미움 없이 객관적으로 자신의 주제에 대해 토론합니다.

예, 여기에 있는 증오의 양이 어마어마합니다. 다음을 고려하십시오.
3587개의 공개 티켓이 있습니다. "좋아요"로 정렬하면 얻을 수 있습니다.
1(이것은) 57 "싫어요"
3586(기타 티켓) 1개 이하의 "추천"

@베소노프

그것이 왜 중요하다고 생각합니까? JSX는 인터페이스를 설명하는 방법입니다. 그 자체로 언어 불가지론입니다. 이봐. 자바스크립트가 아닙니다. 하지만 왜 JSX로 할 수 없습니까? (게다가 (아직) 구현되지 않음)

이것은 _Javascript_에서 UI를 설명하는 방법입니다(따라서 이름의 "JS" 부분). 그리고 아니오, 인라인 DSL이기 때문에 언어에 구애받지 _않습니다_. 그리고 그렇다고 해도 여전히 "더 나은 선택"이 되지는 않습니다. 언어에 구애받지 않는 DSL이 많이 있기 때문에 UI 선언에 비참하게 부적절할 것이기 때문입니다.

그리고.. 아시다시피... 흐름도 fb에서 나옵니다.

Flow는 TypeScript와 같습니다. Javascript용 정적 유형 검사 시스템입니다. React 도구가 아니며 React와 함께 사용하도록 설계되지도 않았습니다. React는 무엇보다도 Javascript 라이브러리이며 JSX는 React와 함께 사용하도록 설계되었습니다. React 개발에 도입된 보조 도구와 유틸리티는 궁극적으로 React+JSX 상호 운용성과 관련이 없습니다.

한 번도 사용하지 않은 확장 프로그램에 대한 찬반 논쟁을 중단하십시오. 나는 JSX를 매일 사용하고 그것에 대해 매우 회의적이었지만 ATM에 만족합니다. JSX가 AngularJS와 마찬가지로 다른 패턴으로 발전한다고 상상할 수 있습니다.

나는 JSX를 사용해 왔으며 그것에 대한 개인적인 의견이 있지만 의도적으로 이러한 의견을 이 토론에서 제외했습니다. 사실, 내 이전 댓글을 읽었다면 내가 React의 UI 개발에 혁명을 일으킨 JSX를 칭찬했다는 것을 알 수 있을 것입니다. JSX 전체의 시장 침투에 대해 내가 했던 약간의 접선적인 의견 외에, 내 주장은 특히 _in Flutter_에서 JSX에 관한 것입니다. 그리고 그 주제에 관해서는 DSX의 효능을 판단할 실질적인 근거가 없으므로 우리가 할 수 있는 일은 JSX가 다른 곳에서 어떻게 구현되었는지 조사하는 것뿐입니다.

물론 DSX를 매일 사용하고 있고 Flutter에서 DSX를 사용할 때의 실질적인 이점을 알려줄 수 없다면?

그리고 이 주제가 더 나은 Dart 패턴을 찾는 데 도움이 될까요? DSX는 하나의 제안일 뿐입니다. 위의 빌더 패턴 예제 또는 여기에 제시된 다른 언어 조정을 보십시오. 그리고, 어쩌면 독감이 더 나은 방법일까요? 모르겠어요. 그러나 다른 사람의 제안에서 나쁜 점에 대해 토론하기 보다는 그것을 찾아내고 서로의 제안을 개선하도록 도와줍시다.

_그렇게 하고 있습니다._ DSX는 JSX에 익숙한 사람들을 위한 UI 솔루션으로 제안되고 있습니다. JSX에는 Dart 및 Flutter와 완전히 다른 환경에서 사용하도록 의도된 주요 디자인 요소가 있습니다. _ DSX가 성공하려면 이러한 차이점을 해결해야 합니다._ 저는 _혐오자_가 아닙니다. 나는 건설적인 토론을 촉진하고 중요한 질문을 하려고 합니다. 그러나 내가 받은 모든 응답은 주관적인 동어반복어("JSX는 미래이기 때문에 좋고 미래가 좋기 때문에 미래입니다"), 중요한 디자인 포인트에 대한 무시무시한 손짓("DSX는 설명할 필요가 없습니다. JS와 Dart 사이의 차이점은 없기 때문에") 또는 그냥 적대적입니다("당신은 분명히 JSX를 좋아하지 않으므로 DSX에 대해 이야기하지 마십시오").

순수한 칭찬만으로는 성공적인 제품을 만들 수 없습니다. 비판에도 대응하고 대응해야 한다. 사람들이 나타나서 "어머, 네, DSX 만들어주세요"라고 하는 것은 기분을 고양시키는 데 도움이 되지 않습니다. 이 스레드 전반에 걸쳐 초기 디자인과 전체 개념 모두에서 DSX에 대해 완벽하게 타당한 비판을 제기한 여러 사람들이 있었습니다. 그리고 대부분의 경우 이러한 비판의 대부분은 아직 직접적으로 다루어지지 않았으며 일반적인 태도는 무시합니다.

내 유일한 두려움은 JSX에 대한 이 모든 무조건적인 사랑이 사람들이 DSX를 객관적으로 보는 것을 방해한다는 것입니다. Flutter에서 JSX와 같은 것을 원하는 이유를 알겠습니다. Flutter에는 전용 UI DSL이 필요하다는 제 생각이 Flui를 만들게 된 이유입니다. 그러나 DSX에 대해 이야기할 수 있는 유일한 사람들이 그것에 대해 좋은 말만 할 수 있다면 그것은 _실패할_ 것입니다.

이 주제에 대한 토론을 재개할 수 있습니까?
사실 이 문제를 계속 열어둘 이유가 없습니다.

Dart 팀은 다른 우선 순위가 있다고 말했습니다. 그리고 프로 JSX 측에서는 자발적으로 DSX 구현을 만들었습니다.

어쩌면 우리는 다른 솔루션을 제안하는 몇 개의 오픈 소스 저장소가 있어야 합니다(간신히 작동하는 경우에도). DSX 또는 템플릿과 같은.
그런 다음 Flutter의 readme 또는 Awesome_flutter에서 이 저장소로 리디렉션하는 것을 고려하세요. 그리고 DSX 구현을 방해하는 것이 있다면 구체적인 내용으로 또 다른 문제를 만드십시오.

그런 다음 커뮤니티가 제 역할을 하도록 하십시오.

사람들이 JSX를 요청하는 새 티켓을 계속 열 것이기 때문에 그대로 두십시오(이미 두 번 발생했기 때문에).

사람들이 JSX를 요청하는 새 티켓을 계속 열 것이기 때문에 그대로 두십시오(이미 두 번 발생했기 때문에).

여기서 차이점은 이제 다음과 같이 대답할 수 있다는 것입니다.

"현재로서는 이것을 dart/flutter에 구현할 계획이 없습니다. 하지만 [여기] 및 [거기] 커뮤니티 대안을 보거나 [이 문제]를 읽을 수 있습니다."

문제를 중복으로 닫습니다.

댓글과 투표를 할 수 있는 곳이 여기 있습니다. JSX와 유사한 기능에 대한 요청은 사라지지 않고 Flutter 도구 지원(컴파일러 및 VS Code IDE)이 필요하고 티켓 요청을 이 정보(첫 번째 주석)로 업데이트했기 때문에 티켓이 열립니다. 엄청난 수의 사람들이 이것을 요구하기 시작하면 Flutter 팀이 여기에 리소스를 투입할 인센티브를 줄 것입니다.

여기에서 논란의 대부분은 현재 JSX가 아니라 DSX에 관한 것 같습니다. DSX 토론을 자체 스레드로 분할하고 이것을 JSX에 일반으로 남겨두는 것이 좋습니다.

결국 DSX는 JSX에 더 가까워지는 하나의 방법일 뿐이므로 우리는 이 두 가지 논의를 하나의 스레드에서 혼합해서는 안 됩니다.

아니오, 저는 1개 언어만 큰 이득이라고 생각합니다. jsx 구문은 js에서 xml을 분리하는 것과 같은 더 많은 것들을 제공할 것입니다... 좋지 않습니다.

제 의견입니다.

그것은 내가 본 가장 길고 무의미한 Github 문제입니다.

@cbazza 잘했어 👍
DSX + 1

@BarryYan , 감사합니다.

"+1"이든 "고마워요"이든 이런 종류의 댓글은 피하세요.
이것은 흥미로운 것을 위해 모든 구독자에게 이메일을 보냅니다.

"+1"이든 "고마워요"이든 이런 종류의 댓글은 피하세요.
이것은 흥미로운 것을 위해 모든 구독자에게 이메일을 보냅니다.

당신에게 흥미로운 것은 없습니다 !!!
사람들이 할 수 있는 말이나 행동을 말하지 말고 당신이 할 수 있는 말이나 행동에만 집중하세요.

@cbazza

형, 기본 에티켓입니다. 이 스레드의 새 메시지는 구독한 모든 사람에게 이메일을 보내므로 토론에 기여하지 않는 댓글을 게시하는 것은 아무 이유 없이 사람들을 짜증나게 하기 때문에 실례입니다. "+1", "고마워요"와 같은 기본적인 리액션은 간단한 엄지척 리액션으로 전달할 수 있으므로 그렇게 하세요.

즉, 이 스레드가 누군가가 "+1" 메시지를 게시해야 하는지 여부에 대해 논쟁하는 것으로 바뀌었다면 모든 건설적인 토론이 공식적으로 중단되었으며 실제로 닫혀야 한다는 큰 위험 신호입니다(아마도 영구적으로 이 시간).

@andrewackerman ,

알지만 이 글을 쓰는 동안 기본 에티켓도 고려해야 합니다.

무의미한 질문(당신도 알다시피, 벽에 많은 쓰레기를 던지고 무엇이 붙는지 확인하십시오)과 요구의 스프레이 및 기도 공세와 함께 FUD(불확실성 및 의심에 대한 두려움)를 퍼뜨리는 것을 중단하십시오.

모든 글을 작성한 후에도 DSX에 가치를 추가하지 않았으므로 이 주제에 대해 귀하와 토론하는 데 관심이 없습니다. 동기는 분명합니다. DSX를 실행하면서 FLUI를 홍보하십시오.

FLUI에 적용했을 때 자신의 질문에 대한 답변이 있습니까? 잠시 FLUI에 대해 알아볼까요?

@cbazza

알지만 이 글을 쓰는 동안 기본 에티켓도 고려해야 합니다.

제가 답변을 '길고 허구적인 글'처럼 잘 생각하고 편향되지 않기 위해 많은 시간과 노력을 들였다는 점을 언급해주시는 것은 당신의 성격과 접근 방식에 대해 많은 것을 보여줍니다. 이 토론. 저는 Flutter에서 JSX를 구현하는 것과 관련된 매우 실제적인 문제에 대한 토론을 촉진하려고 하는 반면 반대 의견을 가진 사람을 맹비난합니다. 우리 중 누가 기본 예절을 더 많이 범합니까?

무의미한 질문(당신도 알다시피, 벽에 많은 쓰레기를 던지고 어떤 것이 붙는지 확인하십시오)과 요구의 스프레이 및 기도 공세와 함께 FUD(불확실성 및 의심에 대한 두려움)를 퍼뜨리는 것을 중단하십시오.

내가 "요구하는" 유일한 것은 DSX와 관련하여 많은 사람들이 제기한 수많은 문제를 일방적이거나 공개적인 적대감 이상으로 해결한다는 것입니다. Flutter의 기능 세트에 중요한 변경/추가를 제안하는 사람에게는 그것이 무리한 기대가 아니라고 생각합니다.

모든 글을 작성한 후에도 DSX에 가치를 추가하지 않았으므로 이 주제에 대해 귀하와 토론하는 데 관심이 없습니다. 동기는 분명합니다. DSX를 실행하면서 FLUI를 홍보하십시오.

나는 _당신에게_ 당신의 입장을 변호할 것을 요청합니다. JSX/DSX가 최고/미래라고 반복해서 말했지만, 아직 어떻게 또는 왜 설명하지 않았습니다. 여러 사람들이 DSX에 대해 타당한 우려를 표명했지만, 이를 해결하는 대신 "마음에 들지 않으면 사용하지 마십시오"라는 반론 뒤에 숨어 이를 떨쳐 버립니다. 제 "동기"는 _모든_ 기술 프로젝트와 관련하여 질문해야 하는 질문에 답하도록 하는 것입니다. 무엇보다도 사람들이 대안보다 이 프로젝트를 사용해야 하는 이유입니다. (그리고 앞서 설명했듯이 친숙함만으로는 충분하지 않습니다.)

FLUI에 관한 한, 내가 하고 있는 일은 전체 문제에 대한 대안 솔루션(Flutter의 UI 선언적 구문)을 제안하는 동시에 사람들에게 내가 DSX에 대해 수행하는 것과 동일한 작업을 수행하도록 요청하는 것뿐입니다. 진지하고 건설적인 비판을 제공하십시오. FLUI가 DSX보다 객관적으로 낫다는 말은 아닙니다. UI 개발에 대한 다른 접근 방식으로 형성된 대안을 제안하고 사람들이 자신의 의견을 형성하도록 요청하는 것입니다.

(또한 GUI 표현에 대한 가능한 대안적 접근 방식을 제안한 초기 언급 외에 FLUI에 대해 이야기한 유일한 시간은 당신이 그것을 꺼냈을 때라는 점을 지적하고 싶습니다. 그래서 어떻게 합니까? 내 숨은 동기가 나보다 당신이 그것에 대해 더 많이 말할 때 그것을 홍보하는 것이 이해가 되십니까?)

FLUI에 적용했을 때 자신의 질문에 대한 답변이 있습니까? 잠시 FLUI에 대해 알아볼까요?

FLUI는 DSX가 아닙니다. FLUI는 DSX와 관련하여 귀하에게 제기한 _모든_ 질문에 답할 필요가 없습니다. 그 중 많은 질문이 DSX의 디자인에만 해당되기 때문입니다. 그렇다고 대답해야 하는 자체 질문 세트가 없다는 말은 아닙니다. 아니요, 저는 모든 대답을 가지고 있지 않습니다. 그것이 내가 비판적인 토론을 중요하게 여기는 _이유_입니다. FLUI/DSX는 몇 번이나 석탄을 가로질러 긁혀서 살아남을 수 없다면 여론의 법정에 서지 않을 것입니다. 그러나 이것은 FLUI를 논의하기에 적절한 장소가 아닙니다. FLUI에 대해 길게 논의하려면 프로젝트에 자체 문제 게시판 이 있으므로 자유롭게 게시하십시오.

비판에 대응하는 대신 방어적이고 회피적인 태도를 취했기 때문에 상황이 너무 뜨거워져서 이 스레드가 일시적으로 닫혀야 했던 두 개의 개별 경우(3개에 가까워짐)에 대해 직접 책임이 있습니다. 그래서 나는 "에티켓"을 깨고 한 번 이렇게 말할 것입니다. 자존심을 세우고, 비판을 인신공격으로 해석하지 말고, 중요한 질문에 답하십시오. 그 중 하나 또는 DSX와 평화를 이루십시오.

andrewackerman 잘했어 👍
+ 1

@andrewackerman

잘 했어

친구, 당신은 칭찬에 엄지 손가락보다 훨씬 더 많은 정보를 전달하는 @jstansbe 로부터 칭찬을 받았고 당신은 칭찬에 엄지 손가락을 댔습니까?

분명히 당신은 길이에 대한 내 힌트를 마음에 새기지는 않았지만 당신이 나를 전혀 모르기 때문에 내 성격에 대해 결론을 내리지 않았습니다.

내가 할 수 있는 한 잘 생각하고 편견 없이 만들려고 많은 시간과 노력을 들인 내 응답을 참조한다는 사실

당신의 '긴 글'을 모두 읽고 감사하게 생각하고 모든 것에 답합니다. 절대 아닙니다. 하지만 제가 제대로 대답하면 당신은 내 대답을 이해하지 못하고 내가 무시하고 있다는 결론을 내립니다.

JSX에 대한 경험이 많지 않고 JSX가 어떻게 작동하는지 이해하지 못하는 것이 분명합니다. 따라서 두 배로 늘리는 대신 소유하고 더 자세히 설명하겠습니다. 예를 들어 JSX 및 DSX는 다음 2가지 변환만 수행합니다(이전에 여러 번 언급됨).

(1)
<A property="a" />
    becomes
new A(property: a)

(2)
<A property="a">
  <B />
  <C />
</A>
    becomes
new A(property: a, children: <Widget>[new B(), new C()])

다른 모든 것은 호스트 언어에 의해 처리됩니다. 예를 들어, 동일한 이름의 구성 요소 가져오기를 처리하는 방법은 다음과 같습니다. 답변: 호스트 언어. 나는 무시하는 것이 아니라 그것이 설계된 방식이며 힘의 원천입니다. 마크업과 프로그래밍을 별도의 파일로 분리하면 'if' 등에 대한 간단한 구성으로 마크업 내부의 프로그래밍을 복제하기 시작합니다. 결국 마크업 내부에 주요 프로그래밍 언어. 따라서 마크업을 프로그래밍 언어로 가져옴으로써 두 가지 장점을 모두 누릴 수 있으며 이것이 바로 JSX/DSX의 장점입니다.

위의 (2)에서 변환 <Widget> 를 하드코딩했지만 항상 그런 것은 아니므로 앞에서 논의한 대로 필요한 경우 지정할 수 있습니다. 변환을 살펴보고 이제 모든 기호는 소스에서 가져오거나 지정할 수 있으므로 미래에 큰 문제가 발생하지 않을 것입니다.

당신이 반대 의견의 어떤 형태로 누군가를 비난하는 동안.

그것은 사실이 아닙니다. 당신은 반대 의견을 가질 수 있지만 내가 달리 증명할 수 있을 때 진실을 주장할 수는 없습니다.

Flutter의 기능 세트에 중요한 변경/추가를 제안하는 사람에게는 그것이 무리한 기대가 아니라고 생각합니다.

하지만 그게 전부입니다. 저는 Flutter 팀이 DSX를 구현하기를 원했지만 DSX에 의존하지 않고 DSX만이 유일한 수혜자가 아니라 구현해야 하는 것은 DSX에 의존하지 않는 일반적인 것이므로 그렇게 했습니다. 브라우저 js 엔진은 js로 변환된 브라우저에서 새로운 언어 생태계를 가능하게 하는 소스 맵을 지원합니다. 그것은 Dart의 생성을 가능하게 했습니다 !!! 및 기타 여러 (Coffeescript, Typescript, Reason 등). Dart는 지금 똑같이 할 수 있으며 모든 보트가 상승하는 데 도움이 되는 생태계의 이점을 누릴 수 있습니다.

나는 당신이 당신의 입장을 변호하기를 요청합니다.

나는 이미 여러 번 했고 결론은 Plain Dart 또는 DSX가 사용자 선호도에 달려 있다는 것입니다. 그리고 중요한 것은 사람들에게 한 가지 방법을 강요하는 대신 옵션을 제공하는 것입니다.

무엇보다도 사람들이 대안보다 그것을 사용해야 하는 이유입니다.

나는 공백이나 탭과 같이 변수 이름 앞이나 뒤에 유형 정의를 선호하기 때문에 DSX를 사용합니다. 그것을 위해 싸우는 것은 의미가 없습니다. 사람들이 다른 선호도를 가지고 있다는 것을 받아들이십시오. 거기에 하나 이상의 프로그래밍 편집기가 있습니까?

친숙함이 충분한 이유가 되지 못한다

그냥 당신의 의견입니다. 거의 모든 언어에서 "if" 문, 'for' 문, 'class', 이제 'asyn/await'를 사용하는 이유는 무엇입니까?

그러나 이것은 FLUI를 논의하기에 적절한 장소가 아닙니다. FLUI에 대해 길게 논의하고 싶다면 프로젝트에 자체 문제 게시판이 있으므로 자유롭게 게시하십시오.

아주 좋아, 이제 당신은 내 존경을 얻었습니다.

이 스레드가 너무 뜨거워져서 일시적으로 닫혀야 했던 두 개의 개별 경우(3개에 가까워짐)에 대한 직접적인 책임이 있습니다.

문제는 그것이 다시 닫히더라도 사람들이 JSX와 같은 기능을 요구하는 것을 막지 못할 것입니다.

자존심을 버리고 비판을 인신공격으로 해석하지 말고 중요한 질문에 답하십시오.

에고는 없지만 성격이 급해서 누가 화를 냈을 때 실수할 일이 없다(바로 나온다). 당신을 화나게 하려는 것은 아니지만 당신의 질문은 중요하지 않았습니다.

그 중 하나 또는 DSX와 평화를 이루십시오.

당신은 성공을 측정하는 데 사용되는 측정기가 아니며 내가 무엇을 하는지도 모릅니다.

친구, 당신은 칭찬에 엄지 손가락보다 훨씬 더 많은 정보를 전달하는 @jstansbe 로부터 칭찬을 받았고 당신은 칭찬에 엄지 손가락을 댔습니까?

당신은 분명히 그의 말에 내재된 풍자를 이해하지 못한 것 같습니다. (그는 말 그대로 내가 하지 말라고 말한 모든 것을 했습니다.) 내가 감사할 수 있는 재미있는 트롤링이지만 여기에서는 적절하지 않습니다. 그리고 우연히 그가 진심이었다면 내 말을 건들었던 것에 대해 사과드립니다. 하지만 제 요점은 여전히 ​​유효합니다. 그런 종류의 댓글은 _여전히_ 여기에서 적절하지 않습니다.

JSX에 대한 경험이 많지 않은 것이 분명합니다...

이 스레드에 대한 나의 첫 번째 코멘트에서 내 면책 조항이 당신에게 팁을 줄 수 있습니까?

...당신은 그것이 어떻게 작동하는지 정말로 이해하지 못합니다.

당신은 내가 JSX에 대한 많은 경험이 없고 그것이 어떻게 작동하는지 전혀 모른다고 동일시합니까? 나는 진지한 React 프로젝트에 대해 작업한 적이 없지만 땜질의 공정한 몫을 했습니다. 나는 그것이 _작동하는 방식을 완벽하게 이해합니다.

다른 모든 것은 호스트 언어에 의해 처리됩니다. 예를 들어, 동일한 이름의 구성 요소 가져오기를 처리하는 방법은 다음과 같습니다. 답변: 호스트 언어.

마크업 언어와 호스트 언어가 다른 경우에 의미가 있습니다. JSX를 사용하면 마크업 언어가 호스트 언어의 _확장_으로 설계됩니다. 이와 같이 JSX는 JS의 확장으로 설계되었으며 이것이 제대로 작동하는 이유입니다. DSX는 Dart용 JSX의 구현입니다.

문제가 보이지 않습니까? 기본적으로 다른 언어로 조작되는 한 언어의 확장으로 설계된 마크업 언어. 많은 문제, 극단적인 경우 및 고려 사항이 있는 것은 _필연적인_ 것입니다.

마크업과 프로그래밍을 별도의 파일로 분리하면 'if' 등에 대한 간단한 구성으로 마크업 내부의 프로그래밍을 복제하기 시작합니다. 결국 마크업 내부에 주요 프로그래밍 언어.

첫째, 마크업과 프로그래밍을 분리하는 이면의 전체 아이디어는 올바르게 수행하는 경우 둘 사이에 명확한 분리가 있어 중복이 _no_ 발생한다는 것입니다.

두 번째로, UI 코드에서 if 및 for 보다 훨씬 더 복잡한 작업을 수행하는 경우(많은 마크업 솔루션에서 쉽게 처리할 수 있는 구성) 다음과 같이 주장합니다. 어쨌든 디자인에 문제가 있다는 신호입니다. MVC/MVVM 디자인 원칙에 따라 UI 구성에 복잡한 논리를 통합하는 경우 코드 냄새가 날 가능성이 있으므로 재설계를 진지하게 고려해야 합니다.

(즉, JSX를 사용하여 MVVM 방식으로 선언적 UI를 작성할 수 _없다는 것은 아니지만, 객관적인 이득이 거의 없는 문제를 야기할 뿐입니다. 사용할 수 있는데도 표준 호환 코드를 작성할 수 있는 것을 사용하는 이유는 무엇입니까? 코드를 작성하기 어렵게 만드는 _그렇지 않은_?)

그것은 사실이 아닙니다. 당신은 반대 의견을 가질 수 있지만 내가 달리 증명할 수 있을 때 진실을 주장할 수는 없습니다.

당신은 아무것도 "증명"하지 않았습니다. 당신은 아직 어떠한 입증 논리도 뒷받침되지 않은 주관적인 주장을 많이 했습니다. (신뢰할 수 있지만 이 최신 게시물은 크게 개선되었습니다.)

하지만 그게 전부입니다. 저는 Flutter 팀이 DSX를 구현하기를 원했지만 DSX에 의존하지 않고 DSX만이 유일한 수혜자가 아니라 구현해야 하는 것은 DSX에 의존하지 않는 일반적인 것이므로 그렇게 했습니다.

당신은 여전히 ​​그들에게 사소하지 않은 일을 하도록 요구하고 있습니다. 따라서 그들과 나머지 사람들을 설득해야 하는 책임은 당신에게 있습니다. 그래서 그들이 해야 할 일과 그들이 해야 할 일 목록에서 다른 일을 미루어야 하는 것이 왜 그렇게 중요한지 설득할 책임이 있습니다.

브라우저 js 엔진은 js로 변환된 브라우저에서 새로운 언어 생태계를 가능하게 하는 소스 맵을 지원합니다. 그것은 Dart의 생성을 가능하게 했습니다 !!!

JS 자체의 특성상 그런 일이 (상대적으로 말해서) 쉽게 할 수 있기 때문에 Dart는 JS에 대한 트랜스파일러가 있는 유일한 언어가 아닙니다. 여러 번 지적했듯이 Dart는 JS가 아닙니다. 이것은 정적이고 강력한 형식을 가지고 있습니다. 즉, JS에서 수행하기 쉬운 많은 작업이 Dart에서는 매우 복잡합니다.

나는 공백이나 탭과 같이 변수 이름 앞이나 뒤에 유형 정의를 선호하기 때문에 DSX를 사용합니다. 그것을 위해 싸우는 것은 의미가 없습니다. 사람들이 다른 선호도를 가지고 있다는 것을 받아들이십시오. 거기에 하나 이상의 프로그래밍 편집기가 있습니까?

그 논리에 따라 16진수로 인코딩된 점자를 사용하여 구문을 정의하는 UI 솔루션을 만들어야 합니다. 제 말은, 정말로 중요한 것이 개인의 취향이라면, 그것의 존재를 옹호하기 위해 내가 말할 필요가 있는 것은 "어떤 사람들은 그것을 선호한다"라는 것뿐입니다. 그렇죠?

당신은 다른 사람들이 사용하도록 의도한 도구를 개발 중이므로 자신을 설득력 있게 만들기 위해 "일부 사람들이 좋아할 것" 이상의 추론이 필요합니다. 당신이 그것을 말로 표현할 수 없다면 _왜_ 그들이 그것을 다른 것보다 사용해야 한다면, 그들이 그렇게 할 것이라고 믿게 만드는 이유는 무엇입니까? 그리고 DSX의 기능 세트를 디자인할 때 그들이 할 것이라고 _보장_하도록 동기를 부여할 수 있는 것은 무엇입니까?

그냥 당신의 의견입니다. 거의 모든 언어에서 "if" 문, 'for' 문, 'class', 이제 'async/await'를 사용하는 이유는 무엇입니까?

첫째, 이러한 키워드( async/await 제외)는 수십 년 동안 C 및 BASIC과 같은 언어의 엄청난 인기로 인해 일반적인 프로그래밍 어휘가 되었습니다. 이전에 언급했듯이 JSX는 수명이 입증되지 않았습니다. 5년 동안 사용되었으며 옵션을 사용할 수 있음에도 불구하고 React 외부에서 중요한 용도는 아직 없습니다.

둘째, 친숙함과 관습 사이에는 큰 차이가 있습니다. if , while , for , struct , class , enum , try/catch/finally , async/await ... 이것들은 모두 개념을 구두로 표현하는 좋은 방법입니다. 사람들에게 익숙한 것 이상으로 이러한 키워드를 사용하는 것을 옹호할 이유가 있습니다. 개념적으로 이해하기 쉽습니다. (물론, 그것이 그들이 상수라는 것을 의미하지는 않습니다. 어떤 언어는 if ... then 합니다. 어떤 언어는 $ if ... elif 를 하고 다른 언어는 if ... else if 를 하고 다른 언어는 if...endif 합니다. foreach , 다른 일부는 $#$ from $#$ , 기타 등등.)

한편, JSX가 '익숙하다'는 이유로 사용하자는 주장은 같은 범주에 들어맞지 않는다. JSX는 선언적 UI를 나타내는 한 가지 방법이지만 유일한 방법도 아니고 가장 인기 있는 방법도 아닙니다. 또한 한 유형의 환경에서 사용하도록 설계되었으므로 다른 환경에서 사용하면 친숙함이 나쁜 것으로 바뀔 수 있습니다. 그러면 _피하고 싶은_ 정신적 단절로 이어지지 않습니다.

문제는 그것이 다시 닫히더라도 사람들이 JSX와 같은 기능을 요구하는 것을 막지 못할 것입니다.

그들은 어쨌든 그것을 요구하고 문제는 똑같이 여기로 리디렉션됩니다. 스레드가 닫히면 어떻게 바뀌는지 알 수 없습니다.

당신은 성공을 측정하는 데 사용되는 측정기가 아니며 내가 무엇을 하는지도 모릅니다.

제품 디자인에 관한 책을 읽으십시오. 1장은 항상 제품이 무엇인지, 왜 사람들이 제품에 관심을 가져야 하는지를 설명하는 성명, 선언문, 슬로건, 일반 영어로 유형적이고 표현할 수 있는 모든 것을 만드는 것에 관한 것입니다. 아마추어 기업가에게 제공되는 가장 일반적인 형태의 조언은 30초 이내에 제품과 추첨을 명확하고 간결하게 전달하는 "엘리베이터 피치"를 만드는 것입니다. 사람들이 당신의 제품을 사용해야 하는 이유를 간결하게 표현할 수 없다면 정체성 위기를 겪고 있다는 신호입니다. 제품을 디자인하는 사람이 비판에 적절히 대응하지 못한다면 자신의 제품에 대한 믿음이 부족하다는 인상을 줍니다. 이 두 가지 모두 투자자에게 큰 위험 신호입니다.

이 상황에서 제품은 DSX이고 투자자들은 그것을 사용을 고려하는 개발자입니다. 당신을 지지하는 유일한 사람들은 설명에 "JSX"가 있는 모든 것을 무조건적으로 응원할 것입니다. 이 스레드의 다른 모든 사람들은 당신이 무엇을 하고 있는지 질문하는 것을 보았습니다.

당신은 현재 전환율이 0%에 가깝거나 그 근처에 있습니다. 그리고 내가 당신이 아직 비판에 적절하게 대응하지 못했다고 말할 때 _그것이_ 나온 것입니다. 신경쓰지 않을 수도 있지만 DSX가 실제 프로젝트에서 사용 가능하고 사용되는 UI 선언 마크업 플러그인이 되도록 진지하게 의도한다면 시작하는 것이 좋습니다.

하지만 다시 말하지만 당신은 예외일 수 있습니다.

좋아, 이 대화는 우리가 Flutter 커뮤니티에서 수용할 수 있다고 생각하는 종류의 토론을 훨씬 뛰어 넘었으므로 이 스레드를 잠그고 버그를 닫겠습니다. 여기에서 우리가 어떻게 행동하는지에 대한 자세한 내용은 https://flutter.io/design-principles/#conflict - resolution을 읽어보십시오.

누군가가 이 문제를 해결하기 위해 코드를 제공하려는 경우 다음 단계는 Gradle, Xcode, 핫 리로드 및 기존 앱과의 통합으로 코드 생성 작업을 수행할 수 있도록 시스템 통합을 구축하는 방법에 대한 디자인을 제시하는 것입니다. 이 작업에 관심이 있는 사람이 있으면 주저하지 말고 저에게 연락하십시오. 그렇지 않으면 이것이 우리가 내년 초에 작업할 것으로 기대합니다. 그렇게 할 수 있는 메커니즘이 있으면 DSX와 같은 솔루션을 Flutter 에코시스템에 쉽게 통합할 수 있습니다. 기본적으로 통합되어야 하는 솔루션을 찾을 수도 있습니다. 그 동안 우리는 UI 표현식을 훨씬 더 쉽게 작성할 수 있는지 알아보기 위해 Dart의 구문을 개선하는 작업도 하고 있습니다.

제기할 가치가 있는 매우 건설적이고 새로운 것이 없는 한 사람들이 이 주제에 대해 새로운 버그를 열지 않도록 요청하고 싶습니다.