-
Notifications
You must be signed in to change notification settings - Fork 29.8k
Description
Currently the flutter widget-preview start command is geared around use in a terminal by a user:
PS D:\Dev\Test Projects\flutter_counter> flutter widget-preview start
Creating widget preview scaffolding at: D:\Dev\Test Projects\flutter_counter\.dart_tool\widget_preview_scaffold
Creating the Widget Preview Scaffold manifest at D:\Dev\Test Projects\flutter_counter\.dart_tool\widget_preview_scaffold\preview_manifest.json
Finding previews in D:\Dev\Test Projects\flutter_counter...
Found 0 previews.
Launching the Widget Preview Scaffold...
Launching lib\main.dart on Chrome in debug mode...
Done loading previews.
This app is linked to the debug service: ws://127.0.0.1:61185/sEoFe2wAsf4=/ws
Debug service listening on ws://127.0.0.1:61185/sEoFe2wAsf4=/ws
Starting application from main method in: org-dartlang-app:/web_entrypoint.dart.
Detected change in D:\Dev\Test Projects\flutter_counter\lib\main.dart.
To help embed inside IDEs, it would be better to have some kind of structured interface so we can read the URLs (and perhaps capture logs etc.) without having to regex the output.
For some of the Flutter tools, there is a --machine flag, and these are usually things where we have two-way communication over stdin/stdout. I think for some Dart tools there is --json which is usually when the output is just one-way and the output is just wrapped in json (no stdin use).
I'm not sure what kind of APIs we might end up with between the editor and preview (and whether they should be direct like this, or over DTD or similar) so I don't know which solution would make most sense at this point.
cc @bkonyi