Profile cover photo
Profile photo
Devon Carew
348 followers
348 followers
About
Devon's posts

Post has shared content
Exciting developments in generated code and the developer workflow :)
v0.5.1+1 of source_gen

Highly experimental. Expect breaking changes.

source_gen provides:

A tool for generating code that is part of your Dart project.

A framework for creating and using multiple code generators in a single project.

A convention for human and tool generated Dart code to coexist with clean separation.

Example

Given a library example.dart with an Person class annotated with @JsonSerializable:

library source_gen.example;

import 'package:source_gen/generators/json_serializable.dart';
part 'example.g.dart';

@JsonSerializable()
class Person extends Object with _$PersonSerializerMixin {
final String firstName, middleName, lastName;

@JsonKey('date-of-birth')
final DateTime dateOfBirth;

Person(this.firstName, this.lastName, {this.middleName, this.dateOfBirth});

factory Person.fromJson(json) => _$PersonFromJson(json);
}

source_gen creates the corresponding part example.g.dart:

part of source_gen.example;

Person _$PersonFromJson(Map json) => new Person(
json['firstName'], json['lastName'],
middleName: json['middleName'],
dateOfBirth: json['date-of-birth'] == null
? null
: DateTime.parse(json['date-of-birth']));

abstract class _$PersonSerializerMixin {
String get firstName;
String get middleName;
String get lastName;
DateTime get dateOfBirth;
Map<String, dynamic> toJson() => <String, dynamic>{
'firstName': firstName,
'middleName': middleName,
'lastName': lastName,
'date-of-birth': dateOfBirth?.toIso8601String(),
};
}

See the example code in the source_gen GitHub repo.

Creating a generator

Extend the Generator class to plug into source_gen.

Trivial example

Included generators

Running generators

source_gen is based on the build package ( pub, GitHub).

See build.dart and watch.dart in the tool directory. Both reference tool/phases.dart, which contains information mapping source_gen generators to target files.

source_gen vs Dart Transformers

Dart Transformers are often used to create and modify code and assets as part of a Dart project.

Transformers allow modification of existing code and encapsulates changes by having developers use pub commands – run, serve, and build.

source_gen provides a different model. Code is generated and updated as part of a project. It is designed to create part files that augment developer maintained Dart libraries.

Generated code MAY be checked in as part of our project source, although the decision may vary depending on project needs.

Generated code SHOULD be included when publishing a project as a pub package. The fact that source_gen is used in a package is an implementation detail.

Post has shared content
A cool view into the internals of the Flutter technology stack!
For today's update, I give you: a video about Flutter!

We've started recording the occasional tech talk about Flutter's technology stack. We're more or less covering topics at random; in this talk I mostly try to answer the frequently asked question "Why does StatelessWidget have a build function on its widget while StatefulWidget has its build function on its State". Adam has a talk prepared where he goes through and explains our rendering pipeline, which hopefully I'll be able to share with you in a few weeks. If there's specific topics you think would benefit from this kind of approach, please don't hesitate to leave a comment.

I'm hoping to turn this talk into a document at some point. I have the speakers notes, which are more or less what I said in the video, it's just a matter of getting the time to do it.

Here's the video link: https://www.youtube.com/watch?v=dkyY9WCGMi0

Post has shared content
The latest Flutter news, hot off the presses!
Over the past few weeks the Flutter team has been mostly focused on performance and testing.

💠‬

For performance, the first step of course is measurement. To this end, Yegor has started doing continuous automated testing on actual devices, so that we have a clear baseline against which to measure our progress. Of course to make that useful we have to have performance tests, so Viktor wrote a test with some complicated layouts. This immediately uncovered that my MixedViewport class was terrible, so Adam rewrote that as LazyBlock. And on it goes.

LazyBlock is pretty neat. Instead of just giving it a list of children, you give it a delegate that produces children on demand, and LazyBlock only asks it for the children that it needs. As you scroll, it throws away the earlier children, and asks for the next ones. If you go back up, it does the same thing backwards. Eventually we'll even make it guess the right child number if you jump scroll, so that you can jump around a huge list of children without ever having to pay the cost of drawing any children other than the ones on the screen.

One widget we don't yet have is a LazyTable. That's something I plan to add soon. I did implement DataTable recently, you can see the demo in our gallery app which exactly matches the sample in the Material Design specification. The next step though is a paginated version and a scrolling version, reusing the same delegate approach that Adam used for LazyBlock. (Tables are tricky because you have to figure out what size to make the columns; for DataTable, it actually measures every cell before laying out any rows, which is quite expensive. For LazyTable, we'll have to use either fixed width columns or flex-style sizing.)

Lots of other work on performance has been going on too. Eric and Devon hooked things up so that from the Atom editor you can now with one checkbox turn on and off our PerformanceOverlay widget and our "repaint rainbow" feature, live while your app is running. Hans has been working on improving the performance of our gallery app. Seth has been running lots of our demo apps tracking down any where we miss frames and filing bugs on them. We even had the help of a nine year old yesterday, who found a bunch of bugs for us!

You can see a screenshot of the checkbox on the PR: https://github.com/dart-atom/dartlang/pull/960

💠‬

The other big push recently has been on testing. As we like to say, "write test find bug". The problem is that writing tests for Flutter has been a bit difficult so far, because you can't see what you're testing.

Yegor has been working on a way to test on-device, using "flutter drive", and as part of that he redesigned our API for testing in a way that makes a lot more sense. (Flutter drive is what he used to do the continuous performance testing I mentioned earlier.) I've now picked that up and I'm taking it to its logical conclusion: make it so that even for our unit tests, you can actually see what's going on if you run them on a device. The hope is that this will really simplify writing tests for Flutter, which will mean we write more tests (and hopefully will mean people writing apps for Flutter can write more tests, since we use the same testing strategy for people writing Flutter apps as we do on Flutter itself), which will mean finding more bugs! 

Post has shared content
Stagehand goes 1.0 :)
Stagehand — the Dart project generator — is now 1.0.0. It's still compatible with 0.2, but we revved to 1.0 to show that it's stable.

I'd never published a package before, so it was nice to see how easy it was to update one.

Post has shared content
I updated the travis build script to support tests written with the test package. Thus no more custom script in .travis.yml is needed to run them.
If your project has the test package in dependencies `pub run test` will be used. If your project uses the old unittest package the tests will still be called with the test_runner package.

Happy testing!

Post has shared content
George's embedding work on DartPad has landed!
This summer I have been working on a project for embedding Dart in webpages. Working with other dart developers and contributors has been an amazing experience and we've tailored this feature to be simple, fast, and intuitive for you!
It's an awesome way to share code and let others try out their own changes - it even runs alongside editable HTML and CSS for web developers. Check it out!

Post has shared content
Check out the new dartdoc beta!  It generates static, mobile friendly documentation for your package. 

Install using 'pub global activate dartdoc’. Learn more at https://pub.dartlang.org/packages/dartdoc

Help us test dartdoc! Use it, file issues at https://github.com/dart-lang/dartdoc/issues. 
Photo

Post has shared content
DartPad, with some UI improvements and upgraded to the latest 1.10.1 SDK!
DartPad is now able to summarize your code when sharing! All shared code on gist will now contain summarization texts that are generated based on associated code. Developers also have the option to edit the summaries before sharing.
The recent release of the DartPad build has also added UI updates and upgraded the backend servers to the latest Dart SDK - 1.10.1. Let us know what you think.

Check it out at https://dartpad.dartlang.org/.
Photo

Post has shared content
This week's upgrade to DartPad adds a little more fit and finish. 

We now auto redirect to the right UI for your device, just go to https://dartpad.dartlang.org and we'll do the rest.

We're also experimenting with a quick fix workflow (e.g. click the wrench at https://dartpad.dartlang.org/3388b2ec6300243768b2). We'd love to hear what you think.
Photo

Post has shared content
Hot off the presses! The 0.7.0 release of grinder.
grinder - Dart workflows, automated.

https://github.com/google/grinder.dart

https://pub.dartlang.org/packages/grinder

+Devon Carew and I are excited to announce grinder 0.7.0. This release completely overhauls the API to be much more darty (awesome!). Here are the highlights:

- Tasks are now defined using an @Task annotation on top-level methods.
- You can now define a default task (@DefaultTask) to run when no tasks are specified on the command line (to the `grind` tool).
- Task functions no longer require a GrinderContext arg, since that is now available as a global context variable whose value is determined by the Zone running the task.
- You can now easily consume pub global activate/run (or pub run) based command-line apps.
- The APIs to copy and delete files, and run processes were cleaned up and extended.
- Added the pub run grinder:init command to initialize a new tool/grind.dart script.

We've been dogfooding the new version in our own projects, and have found the scripts to be much more light-weight and less verbose. If you haven't tried out grinder yet, this release may be a good time to give it another peek. And we have many more features in store for future releases, so stay tuned!

See the README/CHANGELOG for full details. Old APIs were deprecated where possible to provide migration paths to new APIs.

Wait while more posts are being loaded