dart flutter
That’s a genuine question, believe it or not, and I almost find it surprising myself, asking it. There is no denying, having been a JavaScript-based developer for quite a long time now, I had my moments of unshakeable borderline religious belief that JavaScript will eventually take over a huge portion of application development. It’s already a multi-purpose language, and while snobs will call it “just a scripting language” — which it technically is — it has proven its versatility and approachability many-many times. On the web, on mobile (Ionic, React Native, PhoneGap, JQuery Mobile), desktop (Electron, Node-Webkit), embedded, etc. Purely objectively speaking, JS can do a lot, and has done so for nearly 2.5 decades now. Kudos to Brendan Eich and all the other key contributors. We all shall be eternally grateful! 🙏
牛逼的帽子是一个真正的问题，不管你信不信，我几乎觉得奇怪我自己，要求它。 不可否认的是，作为基于JavaScript的开发人员已有很长时间了，我始终坚定地相信，JavaScript最终将接管应用程序开发的很大一部分。 它已经是一种多用途的语言，尽管snobs会称其为“只是脚本语言”(从技术上来说就是这样)，但它已经多次证明了其多功能性和易用性。 在Web上 ，在移动设备 (Ionic，React Native，PhoneGap，JQuery Mobile)， 台式机 (Electron，Node-Webkit)，嵌入式等上。纯粹地客观地说，JS可以做很多事情，并且已经做到了近2.5年。 感谢Brendan Eich和所有其他主要贡献者。 我们将永远感激不已！ 🙏
It goes without saying that JavaScript has single-handedly pushed app development into many next phases and enabled engineers and creatives to take their ideas to platforms previously unavailable to them, but… because there is always a “but”, there is also no denying that just because JS could do all that, it was also not always the best choice for the job. Whenever JS is looked at from a performance aspect, it often ends up being regarded as the sloth of programming languages. Turns out, more often than not, the reality is a bit more nuanced. What creates the impression of a “slow language” might have more to do with the architecture of which it is a part than the language itself. In Ionic you had Angular, the bundled web views cobbled together with Cordova plugins; in React Native you have the bridge between the device’s API and the JS app; in Electron and NWJS an entire headless browser bundled in. Add to that the fact that JS is an interpreted language which makes it inherently 5–10 times slower than a compiled language, and you got yourself an arguable case on both sides of the fence — an argument that Google wants to solve in one fell swoop…
毋庸置疑，JavaScript已将应用程序开发一手推到了许多下一阶段，并使工程师和创意人员可以将他们的想法带到他们以前无法使用的平台上，但是……因为总是有一个“ but”，因此也不能否认仅仅因为JS可以做到所有这些，它也不总是工作的最佳选择。 每当从性能方面看待JS时，它通常最终都被视为编程语言的懒惰。 事实常常是，现实有些微妙。 造成“慢速语言”印象的原因可能与其所涉及的体系结构有关，而不是语言本身。 在Ionic中，您有Angular，捆绑的Web视图与Cordova插件拼凑在一起。 在React Native中，您可以在设备的API和JS应用之间建立桥梁。 在Electron和NWJS中捆绑了整个无头浏览器。此外，JS是一种解释型语言，其本质上比编译后的语言慢5–10倍，并且您在篱笆的两边都有自己的理由— Google一口气想解决的论点...
认识Dart和Flutter… (Meet Dart and Flutter…)
Google’s proposed solution to all your app development dilemmas, world peace and global warming. Hang on. I may have gotten slightly carried away with those last two, but the former is true. Dart and Flutter are presented to the app developer community as a viable alternative to the JavaScript ecosystem. Not a small undertaking, I’ll give ’em that! But it seems to be working…
摹 oogle公司提出的解决方案，以您的所有应用程序开发的困境，世界和平和全球变暖。 不挂断。 我可能对这后两点有些不满意，但前者是对的。 Dart和Flutter作为JavaScript生态系统的可行替代品提供给应用程序开发人员社区。 这可不是一件小事，我会给他们的！ 但这似乎在起作用...
Data seems to indicate that over time the popularity of React Native and Xamarin is in a slow, but nevertheless visible decline, while Flutter is enjoying considerable popularity. Search popularity alone of course doesn’t necessarily give us a full picture, so I went a step further. Take a look at the below screen-grabs:
数据似乎表明，随着时间的流逝，React Native和Xamarin的普及率呈缓慢但仍可见的下降趋势，而Flutter的普及率却很高。 当然，仅搜索流行度并不一定能给我们提供全面的了解，因此我走了一步。 看一下下面的屏幕抓取：
This gives us an even more educated guess and indication that VSCode users have interacted more with Flutter than React Native. Note also the developer experience expressed through the star votes for the two major plugins. Four stars for React Native vs. five stars for Flutter. Now powder me with sugar and call me a donut, but if that all is not an indication that Flutter is on a clear rise, then I don’t know what is.
这给了我们一个更有根据的猜测，表明VSCode用户与Flutter的互动比React Native的更多。 还要注意，通过对两个主要插件的好评来表示开发人员的经验。 React Native为4星，Flutter为5星。 现在给我加糖粉，然后称我为甜甜圈，但是如果这一切都不表示Flutter呈明显上升趋势，那么我不知道这是什么。
So, there’s clearly some bias on my end, hence it’s maybe time to explain myself and why I am both excited and hopeful about the future of Dart and Flutter.
因此，我的目标显然存在一些偏见，因此也许是时候自我解释了，为什么我对Dart和Flutter的未来既兴奋又充满希望。
开发人员经验和工具 (Developer Experience & Tools)
Coming from WebStorm, Android Studio (free!) feels like home, and in my opinion, it’s the ideal IDE for Flutter development. Good news for VSCode fans too, you will be able to use that as well and the Flutter docs will provide you with instructions on how to do that.
C来自WebStorm oming，机器人工作室(免费！)感觉就像回家，在我看来，它是扑开发的理想IDE。 对于VSCode爱好者来说也是个好消息，您也将可以使用它，Flutter文档将为您提供有关操作方法的说明。
Of course, if you’re intending to build and test iOS apps as well, you will have to work on MacOS, and have Xcode installed. You’ll barely touch it other than for some app ID related stuff though. What you really need Xcode for is the iOS simulators, which brings me to one of the dopest things about developing Flutter apps — hot reload. It’s hot indeed. Watching the app reload on the simulator or the actual device in a split second as you hit save, I tell you it’s the sexiest thing I’ve seen in a long time in software development. It’s also worth noting that there are two types of reloading in Flutter:
当然，如果您还打算构建和测试iOS应用，则必须在MacOS上工作，并安装Xcode。 除了一些与应用程序ID相关的内容之外，您几乎不会碰它。 您真正需要Xcode的是iOS模拟器，这使我想到了关于开发Flutter应用程序最完美的事情之一-热重装。 确实很热。 当您点击保存时，看着应用程序在一秒钟内重新加载到模拟器或实际设备上，我告诉您这是我很长时间以来在软件开发中所见过的最性感的事情。 还值得注意的是，Flutter中有两种重装类型：
热装 (Hot reload)
This only repaints the widget that was changed in the widget-tree of your code, because of the code-changes you made. Anything unaffected by that code-change, will stay as is, including your app’s state. This is blazing fast.
由于您所做的代码更改，这只会重绘代码的小部件树中已更改的小部件。 不受代码更改影响的所有内容将保持原样，包括您应用的状态。 速度很快。
Performing hot reload...
Syncing files to device iPhone SE (2nd generation)...
Reloaded 3 of 511 libraries in 396ms.热重启 (Hot restart)
This repaints the entire app, and the state gets wiped away as well. This, while a bit slower than hot reload, it’s still incredibly fast.
这将重新绘制整个应用程序，并且状态也将消失。 这虽然比热重装要慢一点，但仍然非常快。
Performing hot restart...
Syncing files to device iPhone SE (2nd generation)...
Restarted application in 1,153ms.Refactoring code is something inescapable to every developer or engineer, so being able to confidently “break” your own code with as little disruption and “collateral damage” as possible, with the intent of making it better, is nothing shy of a superpower that Flutter in combination with Android Studio give you. Here are just a few examples.
重构代码是每个开发人员或工程师都无法避免的事情，因此能够放心地“破坏”您自己的代码，并尽可能减少破坏和“附带损害”，以使其变得更好，这并不意味着Flutter拥有超能力与Android Studio结合使用可为您提供。 这里只是几个例子。
使用dartfmt重新格式化代码 (Reformat code with dartfmt)
Clean-looking code is important in Flutter, as nested widgets can quickly look like a spaghetti rabbit-hole, but this reformatting tool puts everything into place, looking all nice and tidy. It’s also smart enough that if you put commas between your widgets, it will perform the reformatting action as you save the file, so you don’t have to manually trigger it.
外观整洁的代码在Flutter中很重要，因为嵌套的小部件可以很快看起来像一个意大利面兔子Kong，但是此重新格式化工具将所有内容放置到位，看起来很整洁。 足够聪明的是，如果在小部件之间放置逗号，则在保存文件时它将执行重新格式化操作，因此您不必手动触发它。
转换为StatefulWidget (Convert to StatefulWidget)
Just like in React, in Flutter you’ll also find stateful and stateless components called widgets. It happens more than a few times during the development of an app that you suddenly realise, your stateless widget actually has to be stateful. This takes a single click in Flutter, as illustrated below (note: these options become available via the little lightbulb dropdown, which you will get for all widgets).
就像在React中一样，在Flutter中，您还将找到有状态和无状态组件，称为小部件。 在突然意识到的应用程序开发过程中，这种情况发生了多次，无状态小部件实际上必须是有状态的。 只需在Flutter中单击一下，如下图所示( 注意：这些选项可通过小灯泡下拉列表使用，所有小部件都将提供该选项 )。
Pro tip: when you create a new widget you can also just type stless or stful and it will auto-generate a stateless and a stateful widget respectively.
专家提示：创建新的小部件时，您也可以只键入stless或stful ，它将分别自动生成无状态小部件和有状态小部件。
用...包裹 (Wrap with …)
This is another one that aims to reduce complexity and make an otherwise error-prone action, simple and bulletproof. As you build your Flutter UI, you will often find you will want to wrap your components with a Container, Row or Column. The Flutter Outline in Android Studio allows you to do that with a single click. This side-menu also allows you to extract a method or a widget, further aiding refactoring efforts.
这是另一个旨在降低复杂性并采取易于出错的动作的简单，防弹的动作。 在构建Flutter UI时，通常会发现您希望使用Container，Row或Column包装组件。 Android Studio中的Flutter Outline允许您单击一下。 此副菜单还允许您提取方法或小部件，以进一步帮助重构工作。
Copy/cut-paste? Get outta here. That’s so last year… As you’re extracting your widget, it will ask you to name it, and voila, you have yourself a custom widget separated out, and that widget name is also applied where you cut out your chunk of code from! It’s magic!
复制/剪切粘贴？ 你出去。 去年真是这样……在提取小部件时，它会要求您命名，瞧，您将自己的定制小部件分离出来，并且该小部件名称也将应用到您从中切出代码块的地方！ 这是魔法！
There are even more actions if you use the wee lightbulb dropdown, all very useful. Wrap with widget, for instance, wraps your selected widget tree with an anonymous widget which you then can turn into whatever widget you like.
如果使用wee lightbulb下拉菜单，则还有更多操作，这些操作非常有用。 例如，“ 使用小部件包装”会将您选择的小部件树包装成一个匿名小部件，然后您可以将其转变为所需的任何小部件。
Wrap with StreamBuilder is also handy as it allows for quickly setting up your component to take data from a service such as Firebase and replicate the child component based on the data it listens to.
使用StreamBuilder进行包装也很方便，因为它允许快速设置您的组件以从Firebase等服务中获取数据，并根据其侦听的数据复制子组件。
The list of handy tools you will find in Android Studio to build, refactor, run and test your app is nearly limitless. Hands down the best ever developer experience I had. But, it’s not all down to the IDE…
您将在Android Studio中找到用于构建，重构，运行和测试您的应用程序的便捷工具，几乎无穷无尽。 传授我有史以来最好的开发人员经验。 但是，这还不完全取决于IDE ...
社区和文件 (Community and documentation)
Exactly. Because you can have great tools all you want, if the docs are crap, and the community is either very small or novice, frustration will mount. Thank the gods of Kobol, this is not the case with Flutter and Dart. Flutter has grown a solid community around itself in 4 years — its inception was in 2017 — and googling issues will bring up plenty of solutions on StackOverflow. The even better news is that you actually won’t have to do that too often. The documentation is stellar, and this is something I noticed before. Google (and this is big coming from me, who always has a bone to pick with the mighty Google) really knows how to write developer-friendly, detailed documentation with easy to digest and reusable examples. This is incredibly important when picking up both a new language and a new framework. The integration with Firebase is also exceptional and well documented.
究竟。 因为您可以拥有所有想要的强大工具，所以如果文档太糟糕了，并且社区很小或者是新手，那么沮丧就会越来越大。 感谢Kobol的众神，Flutter和Dart并非如此。 Flutter在4年内(其成立于2017年)在其周围建立了一个坚实的社区，而谷歌搜索问题将为StackOverflow带来大量解决方案。 更好的消息是您实际上不必经常这样做。 该文档非常出色，这是我之前注意到的。 Google( 这对我来说是很大的，我总是有能力选择强大的Google )，他确实知道如何编写易于开发和重用的示例的开发人员友好的详细文档。 在选择新语言和新框架时，这非常重要。 与Firebase的集成也很出色，并且有据可查。
Now, don’t get me wrong, I see why Google does this. It’s a lot more than just being nice to developers. It’s a hook to lure us into their development and build ecosystem, and they’re succeeding. While I am an Apple fan for many-many reasons, when it comes to developing for Apple, I can’t say it’s a painless and frustration-free experience. The learning-curve is also pretty steep, and the tools, while solid, are definitely not the most intuitive. Flutter and Dart has a huge potential to lure people away from Swift and Xcode.
现在，请不要误解我，我明白了Google这么做的原因。 这不仅仅是对开发人员友好。 吸引我们进入他们的发展并建立生态系统是一个钩子，他们正在成功。 尽管我出于许多原因成为Apple迷，但在为Apple开发方面，我不能说这是一种无痛且无挫折的体验。 学习曲线也非常陡峭，虽然工具扎实，但绝对不是最直观的工具。 Flutter和Dart具有诱使人们远离Swift和Xcode的巨大潜力。
You don’t care much about official documentation? No bother, as mentioned before, there are plenty of discussions happening already on StackOverflow, so you’ll be in great company!
您不太在乎正式文档？ 不用担心，如前所述，关于StackOverflow的讨论已经很多，因此您将与大公司保持联系！
Flutter令人耳目一新 (Flutter is Refreshingly Beautiful)
设计系统 (Design system)
Flutter follows the Material design system and does it so religiously. I like that. It allows for predictability in my designs and overall UX, but without taking away the flexibility of applying my own artistic flavour to it.
˚Flutter如下材料设计系统，并做这么虔诚。 我喜欢。 它使我的设计和整体用户体验具有可预测性，但又不影响将我自己的艺术风格应用于其中的灵活性。
In Flutter everything in the UI is a widget, and all of these widgets allow for customisation at any level. You can go down the rabbit hole of material design, as low as shape primitives like square and circle which form your UI components. The bottom line is, Flutter doesn’t have to look like a vanilla Google app. Having said that, if you’re not great at design or you don’t have the time and expertise to roll your own versions of the widgets, creating an app with bog-standard Material widgets will absolutely result in a good-looking, intuitive, familiar and reliable application, and often times that’s all one really needs to get their idea, app or business off the ground.
在Flutter中，UI中的所有内容都是一个小部件，所有这些小部件都允许在任何级别进行自定义。 您可以沿着材质设计的灵丹妙药，低至构成UI组件的形状原语(例如正方形和圆形)。 最重要的是，Flutter不必看起来像普通的Google应用。 话虽如此，如果您不擅长设计，或者您没有时间和专业知识来滚动自己的小部件版本，那么使用沼泽标准的Material小部件创建应用程序绝对会带来美观，直观的效果，熟悉且可靠的应用程序，而且往往是真正使他们的想法，应用程序或业务发展所需的全部时间。
Cupertino小部件 (The Cupertino widgets)
For those familiar with hybrid mobile apps, the concept of opinionated design and UI on both the Apple and Google front is nothing new, so naturally the question arises — but what about my UI elements that are very Apple specific, like the picker? You’ll be happy to hear, Flutter has you covered, and to explain that, I need to sneak in a very exciting piece of information — Flutter supports six (6!) operating systems. By simply checking whether I am running the app on an iOS device or not, I can load the iOS version of the component that is provided out of the box by Flutter via the Cupertino Widgets package or I can load the Android flavoured widget. Note, you don’t have to, all Flutter components work just fine on iOS as well, but most UX and design professionals will agree that you want apps running on iOS to look and behave in the expected manner.
对于那些熟悉混合移动应用程序的人来说，Apple和Google方面的固执己见的设计和UI的概念并不是什么新鲜事物，因此自然就产生了问题- 但是我的UI元素是Apple特有的，例如选择器呢？ 您会很高兴听到Flutter的服务，并向您解释，我需要了解一些非常令人兴奋的信息-Flutter支持六(6！)操作系统。 通过简单地检查我是否在iOS设备上运行该应用程序，我可以通过Cupertino Widgets软件包加载Flutter提供的即装即用的组件的iOS版本，也可以加载Android风格的Widget。 请注意，您不必一定要确保所有Flutter组件在iOS上也能正常工作，但是大多数UX和设计专业人员都会同意您希望在iOS上运行的应用以预期的方式外观和行为。
If you’re suddenly wondering whether this kind of negates the “one code-base” philosophy or not, I would say it’s splitting hairs at this point. There are a total of 24 Apple-specific widgets, out of which realistically speaking each app will use maybe three or four. If it’s a very large application, maybe eight or ten. From my perspective this is a very small price to pay for an otherwise identical code-base that can compile to multiple OSs and the web. If you’re a smart engineer, you will keep your logic and data manipulation as OS-agnostic as possible in which case the OS-specific code will be minimal.
如果您突然想知道这种否定的否定“一个代码库”的理念，那我会说这是一头雾水。 总共有24个Apple特定的小部件，实际上每个应用程序可能会使用三个或四个。 如果是非常大的应用程序，则可能是八个或十个。 以我的观点，这是可以以很小的代价购买可以编译到多个OS和Web上的相同代码库。 如果您是一位聪明的工程师，则将使逻辑和数据操作尽可能与OS无关，在这种情况下，特定于OS的代码将最少。
声明式用户界面 (Declarative UI)
I must admit, before Flutter, I didn’t even realise declarative programming existed — well, there is CSS, but I always tend to forget about that — but it does and that’s the paradigm Flutter uses for the UI. If you’re interested in the details, your best bet is in the Flutter docs itself. No use in me attempting to explain it, as it would just be pointless regurgitation of their docs anyway.
我必须承认，在Flutter之前，我什至没有意识到声明式编程的存在- 嗯，有CSS，但是我总是会忘记这一点 -但这确实是Flutter用于UI的范式。 如果您对这些细节感兴趣，最好的选择是Flutter文档本身。 对我来说，试图解释它没有用，因为反正他们的文档毫无意义。
国家管理 (State management)
If you’ve ever written a React app, dealing with state is nothing new to you. If you’ve written more than one React app then you’re likely intimately familiar with the bloodiest of battles between developers over state management. It is vicious! Couples break up over it. Decades long friendships go down the toilet, relatives disown each other, it is a massacre. It’s one of the reasons why I never truly fell in love with React. It’s a decent library, but it’s also a source of contention and bad blood between developers.
如果您曾经编写过React应用，那么处理状态对您来说并不是什么新鲜事。 如果您编写了多个React应用程序，那么您可能非常熟悉开发人员之间在状态管理方面的最血腥的战斗。 真是恶毒！ 夫妻分手了。 几十年的友谊长久以来都落在马桶上，亲戚互相嘲笑，这是一场屠杀。 这就是我从未真正爱上React的原因之一。 这是一个不错的库，但是它也是开发人员之间争执和鲜血的来源。
Naturally, the moment I realised Flutter had two types of widgets: stateful and stateless, I started worrying this will be yet another framework with the same kind of blood-shed and philosophical debate over how one should manage the state. Maybe I’ve gotten increasingly zen over the last couple of years, but I cannot possibly spend another minute arguing about things that genuinely don’t bring any tangible value to the resulting product. The only thing I can agree on is that state management is necessary in an application. How exactly one should do it largely depends on the application and its purpose.
自然地，当我意识到Flutter具有两种类型的小部件：有状态的和无状态的小部件时，我开始担心这将是另一个框架，该框架具有关于如何管理状态的流血性和哲学性辩论。 在过去的几年中，也许我变得越来越禅宗了，但是我不可能再花时间争论那些真正不会给最终产品带来任何实际价值的事情。 我唯一可以同意的是状态管理在应用程序中是必需的。 究竟应该怎么做很大程度上取决于应用程序及其目的。
In Flutter there are three major ways you can manage your state. Neither of these is good or bad, each fits a specific scenario and should be applied as such.
在Flutter中，可以使用三种主要方法来管理状态。 这些都不是好事，都适合特定的情况，应照此应用。
Local state with setState() — this is as simple as it gets. You have your component or view, you set a variable, you run the
setState()function inside which you change that variable’s value. If your app doesn’t do much, this approach is fine.使用setState()的本地状态 -这很简单。 您有组件或视图，设置了变量，然后运行
setState()函数，在其中更改了变量的值。 如果您的应用程序执行不多，则此方法很好。Lifting the state — this method results in prop drilling, something that every React developer learned to hate very early on. You basically have your state inside the parent, and you pass the values and callbacks down to the subsequent children, one child at a time which then use callbacks to change the parent’s state again. It becomes very difficult to maintain very quickly, but good enough for a small app.
提升状态 -这种方法会导致道具钻探，这是每个React开发人员都非常早就学会讨厌的东西。 基本上，您可以在父级中拥有状态，然后将值和回调传递给后续子级，一次一个子级，然后使用回调再次更改父级的状态。 快速维护变得非常困难，但是对于小型应用程序来说已经足够了。
Provider + Consumer — this is the scalable method and the one recommended by Google. Flutter Provider is actually a community developed solution started by Remi Rousselet, who is also attempting to add hooks capabilities to Flutter, something I may or may not be enthusiastic about. Regardless, the provider-consumer solution is certainly a good one, and works well and is required for larger or scalable apps.
提供商+消费者 -这是可扩展的方法，也是Google推荐的方法。 Flutter Provider实际上是由Remi Rousselet发起的社区开发的解决方案，他也试图向Flutter添加挂钩功能，这可能使我兴奋也可能不兴奋。 无论如何，提供商-消费者解决方案无疑是一个很好的解决方案，并且运行良好，是大型或可伸缩应用程序所必需的。
Dart是Kinda Cool！ (Dart is Kinda Cool!)
欢迎回到OOP。 (Welcome back to OOP.)
Dart feels a lot like TypeScript, without the constant horrifying thought in the back of my mind that it all compiles down to JavaScript and the sole reason for its existence is some Microsoft engineers couldn’t deal with the fact that JavaScript was a scripting language and didn’t support static typing or interfaces. As I kept writing Dart though, I started enjoying some of the cool features it brought to my code.
D art感觉很像TypeScript，在我脑海中一直没有持续的恐怖思考，认为它们都可以编译为JavaScript，而其存在的唯一原因是有些Microsoft工程师无法处理JavaScript是一种脚本语言的事实。并且不支持静态类型或接口。 但是，当我继续编写Dart时，我开始享受它为代码带来的一些很棒的功能。
First of all, it’s an object oriented programming language, and while functional programming zealots would have you believe OOP is an abomination, the fact of the matter is the top 10 or so currently popular programming languages are all either entirely or at least partially OOP, but definitely not on the functional programming paradigm bandwagon. And there is a very good reason for that. The OOP paradigm is organic. Objects emulate the real world, the way the human brain works. Humans understand things and their properties, what those properties are/do and where they sit in the context of other things and their own respective properties. It makes sense, whereas in functional programming all that is thrown out the window, forcing one to self-inflict migraines to digest 10 lines of code that in OOP would have just made sense in a matter of seconds. Sure, in the long run, one might rewire their brain to think functionally, but statistics currently show there is little to no appetite for that in the larger software engineering community, so sticking to OOP and thus to Dart is not a bad bet.
首先，它是一种面向对象的编程语言，尽管函数式编程狂热者会让您相信OOP是令人讨厌的，但事实是，目前流行的前10种编程语言全部或至少部分是OOP，但绝对不是函数式编程范式的潮流。 这有一个很好的理由。 OOP范例是有机的。 物体模仿人的大脑工作方式的真实世界。 人类了解事物及其属性，这些属性的作用/作用以及它们在其他事物的上下文中所处的位置以及它们各自的属性。 这是有道理的，而在函数式编程中，所有的一切都被丢掉了，迫使一个人自我偏头痛地消化10行代码，而这在OOP中只需几秒钟就可以了。 当然，从长远来看，人们可能会重新思考大脑进行功能性思考，但是目前的统计数据表明，在大型软件工程界对此几乎没有胃口，因此坚持使用OOP并坚持使用Dart并不是一个坏选择。
const vs.决赛 (Const vs. Final)
This was new to me, and so far no UI developer I talked to heard about a similar concept before. In Dart you have not one but two kinds of constants. My initial reaction was WT-actual-Fudge?!? It turns out in Dart const is used as a compile-time constant, while final is a run-time constant. Why is this useful you ask? Well, there are plenty of cases where you want the option to set a variable to a value dynamically, and then never ever change that value for the life of the app. Very useful when you want to set some initial values coming from an API that you know are not supposed to change afterwards. It could also help with securing your app, as outside attempts to manipulate the value of a final will fail miserably; say the price of a product for example.
这对我来说是新手，到目前为止，我从未与之交谈过的UI开发人员听说过类似的概念。 在Dart中，您没有一种常数，而是两种常数。 我最初的React是WT-actual-Fudge？！？ 事实证明，在Dart中const用作编译时常量，而final是运行时常量。 您问这个为什么有用？ 好吧，在很多情况下，您都希望选项可以动态地将变量设置为一个值，然后在应用程序的生命周期内永远不要更改该值。 当您想设置一些您知道以后不应更改的API的初始值时，此功能非常有用。 这也可能有助于保护您的应用程序安全，因为外界试图操纵final的值会惨败； 例如说产品的价格。
私人财产 (Private properties)
Another great feature I wish I had in JavaScript is private properties. Setting myAmazingProperty to _myAmazingProperty and thus reducing the scope of its availability to that component and that component or class only, is incredibly useful. Makes code less bug-prone, easier to read and debug.
我希望我在JavaScript中拥有的另一个很棒的功能是私有属性。 将myAmazingProperty设置为_myAmazingProperty ，从而减小其对该组件以及仅该组件或类的可用性范围非常有用。 使代码更不易出错，更易于阅读和调试。
枚举 (Enums)
This is another nice trick up Dart’s sleeve. I wish JavaScript came with this out of the box, without having to resort to what this guy suggests in his blog-post. Enums in Dart look great and make a lot of sense too. Take for instance this example:
这是Dart袖子上的另一招。 我希望JavaScript开箱即用，而不必求助于此人在其博客文章中建议的内容 。 Dart中的枚举看起来很棒，也很有道理。 以这个例子为例：
enum Status {
none,
running,
stopped,
paused
}
void main() {
print(Status.values);
Status.values.forEach((value) => print('value: $value, index: ${value.index}'));
print('running: ${Status.running}, ${Status.running.index}');
print('running index: ${Status.values[1]}');
}You’re welcome to play around with the code yourself in dartPad.
但是等等，还有更多…… (But wait, there’s more…)
Dart is a great language not just because it’s OOP, or because it has the features I mentioned. Those are just the ones that stood out to me. There is plenty more, of course, where those came from. Futures (async/await), arrow functions, null aware operators, mixins, streams. There are a lot of goodies in Dart and I highly recommend taking the official Dart tour.
Dart是一种很棒的语言，不仅因为它是OOP，还是因为它具有我提到的功能。 这些只是对我突出的那些。 当然，还有更多的来源。 期货(async / await) ， 箭头函数 ，可识别 null的运算符 ， mixin ， 流 。 Dart有很多好吃的东西，我强烈建议您参加Dart官方之旅 。
For a barely eight year old language, Dart feels incredibly stable and feature-rich. Being a descendant of the ALGOL (algorithmic language) family, it’s also no surprise it shares traits with C, C#, JavaScript, Java and a good few others. The syntax is easy to pick up if you’ve written any of the above languages before, and especially so if you have at least dabbled in TypeScript or Angular in the past.
对于只有八岁的语言，Dart感觉非常稳定且功能丰富。 作为ALGOL(算法语言)家族的后代，它也与C，C＃，JavaScript，Java和许多其他产品具有相同的特性也就不足为奇了。 如果您之前已经写过上述任何一种语言，那么语法就很容易掌握，尤其是如果您过去至少接触过TypeScript或Angular时，尤其如此。
尝试回答我自己的问题… (An Attempt to Answer my Own Question…)
By all means, my conclusion could be seen as controversial, and you’re more than welcome to share your thoughts in the comments, but here’s my take on it anyway. For the first time in a very long time we have a genuine contender for the cross-platform development crown. That is indubitably a good thing.
通过一切手段，我的结论可以被看作是有争议的，和你比欢迎更多在评论中分享你的想法，但这里是我采取的也无妨。 很长时间以来，我们第一次有真正的竞争者来参与跨平台开发。 这无疑是一件好事。
From where I stand, Flutter is a brilliant framework built on top of a well thought-out, familiar-feeling language, called Dart. It levels the mobile app development playing field and opens it up to a whole lot more developers and creative professionals who want their apps out there, in the wild, for people to use.
从我的立场来看，Flutter是一个出色的框架，建立在经过深思熟虑，感觉熟悉的语言Dart之上。 它为移动应用程序开发提供了一个公平的环境，并为更多的开发人员和创意专业人士打开了大门，他们希望野外发布自己的应用程序供人们使用。
Flutter also has a huge potential in saving companies anywhere between thousands and millions yearly by providing a reliable design language, familiar UX, intuitive and mature developer tools, so that product teams can do what they do best — focus on building great products for customers. Flutter is an exciting prospect of living in a world where one can deploy one code-base to mobile, desktop and the web. Now this is the kind of innovation I can truly get excited about. Only time will tell of course whether the current trend in popularity will be sustained and what current development trend it will displace. Ionic was once the go-to solution for mobile hybrid development only to be quickly overtaken by React Native. Seeing how the developer community’s interest for Flutter and React Native seems to be already at least neck-and-neck, I for one feel that the hope is warranted for a future full of Fluttery goodness. 😁
Flutter还具有巨大的潜力，通过提供可靠的设计语言，熟悉的UX，直观且成熟的开发人员工具，每年可为成千上万的公司节省成本，使产品团队能够尽其所能-专注于为客户打造出色的产品。 Flutter是生活在一个可以将一个代码库部署到移动，桌面和Web的世界中的令人兴奋的前景。 现在，这种创新让我真正感到兴奋。 当然，只有时间会证明当前的流行趋势是否会持续下去，以及它会取代当前的哪种发展趋势。 Ionic曾经是移动混合开发的首选解决方案，但很快被React Native取代。 看到开发人员社区对Flutter和React Native的兴趣似乎已经至少并驾齐驱，我感到一个希望，是对充满Fluttery美好未来的希望。 😁
Attila Vago — Sr. Software Engineer building amazing educational software. Cool nerd since forever, writer of codes and blogs. Web accessibility advocate. Lego fan. Loves craft beer!
Attila Vago — 高级软件工程师，开发出色的教育软件。 自古以来就是酷书呆子，是代码和博客的作者。 Web无障碍倡导者。 乐高粉丝。 喜欢精酿啤酒！
dart flutter
9109
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
