Add a way of interacting with the app you build

[filiph]

Dart is a "client-optimized language", so most folks are trying to build things that are interactive in some way.

Right now, the only way of building anything interactive in DartPad is using HTML. Which is a cognitive load, and wasted effort for newcomers who don't want to deal with HTML (e.g. Flutter newcomers).

One way of doing user interaction is to allow importing dart:io, but 99% of dart:io is unnecessary for this scenario. And I'm sure that would mean a lot of security work on top.

@kwalrath proposed a custom stream of events. Here's how it would work (in my understanding):

• There is some minimal UI in the OUTPUT / CONSOLE panel. It can be just one button, or two, or a set of basic inputs (button, slider, text input). These inputs are styled to be integral parts of the DartPad UI.
• DartPad scripts have access to a Stream of events that come from that UI.
  • It can be a global field per UI element, something like Stream<Null> buttonClicks; and Stream<String> textInputs;.
  • Or it can be a single field of Stream<DartPadEvent> uiEvents but that would have to be documented somewhere.
• Optionally, the UI and the access to the stream is only enabled when user starts the script with a magic import, something like import 'dartpad:ui';.
• print() is the only output

The cool thing about this is that:

• We're teaching streams and reactive programming from the get go.
• Unlike HTML, the API is simple. You don't need to explain how querySelector works.
• UI is isolated. You don't need to aggressively guard against stuff happening in the HTML embed for security reason, because you can't modify anything about the UI. You can only print.

cc @montyr75

[kwalrath]

To be clear, @filiph thought of almost all of this. :) But I'd love a way to make DartPad a bit more client friendly without requiring HTML. Streams, in particular, are pervasive but can be hard to understand until you use them.

[devoncarew]

So to paraphrase a bit, instead of just stdout, have the snippet run in a container environment, with some way for the snippet to get events from the container, and provide feedback to it. Perhaps a bit like a micro version of http://processingjs.org/? Having a special package: import or similar to make the container's inputs available makes sense.

We're teaching streams and reactive programming from the get go.

Smaller demos of the streams API could also be taught via periodic Timer events.

[filiph]

@devoncarew Yes. Very well put, and the simile to Processing is great (although, of course, we'd be a long way behind what processing can do).

Timer works, but I think it's significantly more educational/visceral/interesting when you can "play" around with the code you build.

[filiph]

This relates to https://github.com/dart-lang/dart-pad/issues/820 (remove the ability to write and execute html in the snippets).

[RedBrogdon]

@filiph @devoncarew Where do you stand on this idea in relation to flutter_web? Would it be simpler to provide the dev with Flutter code pre-built (possibly in a test tab as we do in the new embed UI) and then let them hook into that with their Dart? That would allow us to use and flutter_web infrastructure and still give them an interactive experience.

[filiph]

That would be the absolute best, yes. If we have a Flutter view to interact with, there is no need to implement a separate thing described above.

[parlough]

That would be the absolute best, yes. If we have a Flutter view to interact with, there is no need to implement a separate thing described above.

Since building simple Flutter web apps is supported by DartPad now, I'm going to close this as we can support all types of interaction through that view :)