Enhancements for embedded use cases

[mike-north]

I'd like to make three enhancements to ember-twiddle, that open up some interesting use cases for embedding twiddles into a larger app (i.e., for tutorial purposes).

Before I set out to make these changes, I would love some feedback about whether this is a desirable direction to go in.

1. make the "live reload" and "run tests" checkboxes queryParam driven
2. allow the twiddle (the running app) to communicate with the app embedding the twiddle via postMessage
3. additionally, send information about tests passing/failing to the app embedding the twiddle, via postMessage. I have a qunit addon that already does the bulk of the work https://github.com/mike-north/qunit-events

[Gaurav0]

1. I'm of the opinion that "live reload" should be a user preference. "run tests" is already saved in twiddle.json. We don't have a setup for saving user preferences to localStorage yet, but overriding what the user prefers really shouldn't be done in the case of "live reload" imo.

For the use case of embedded twiddles for learning, we can create a query param driven option to hide the output pane in the embedded view.

2. +1 You can build on the postMessage Ember Twiddle itself uses to update the address field.
3. +1

[toddjordan]

+1 Making this happen would be fantastic for using twiddle as an interactive aid for learning materials.

[mike-north]

I'm of the opinion that "live reload" should be a user preference.

This sounds fine to me. In line with #517, I would love to see an option for users to opt out of it being enabled by default.

Typically this pattern works well for these kinds of things

• If something is explicitly specified, honor it (i.e, ?liveReload=true in the url)
• otherwise fall back to the user's preference (would make #517 supporters happy)
• and the user preference defaults to "enabled" (would keep twiddles out in the wild operating as they have been)

"run tests" is already saved in twiddle.json.

This feels more like state than configuration to me. I've accidentally saved twiddles while "run tests" was checked, and been surprised that this setting "stuck" for those who I sent the twiddle link to.

Here's an example where I think we can all agree that embedding with tests running is a good option for twiddle authors to have: https://ember-twiddle.com/abe0fcd1cde655f9bfd4a694764af625?fileTreeShown=false&openFiles=utils.course.js

[Serabe]

I have a use case for live reload being in the twiddle. We ask users to send reproductions of bugs in an Ember Twiddle. If live reload is persisted in query params, we won't need to worry about our personal preferences making our browser crash when opening a reproduction.

Thank you!

[Gaurav0]

Typically this pattern works well for these kinds of things

If something is explicitly specified, honor it (i.e, ?liveReload=true in the url) otherwise fall back to the user's preference (would make #517 supporters happy) and the user preference defaults to "enabled" (would keep twiddles out in the wild operating as they have been)

Given @Serabe 's comment, I've come around. I think this is workable. We should make sure a user preference is implemented first.

This feels more like state than configuration to me. I've accidentally saved twiddles while "run tests" was checked, and been surprised that this setting "stuck" for those who I sent the twiddle link to.

I think your use case is the exception, in my experience, most of the time people who have tests want it enabled. Plus, when tests are initially enabled, large amounts of code get added to the twiddle.

In any case, changing it to a query param doesn't solve this problem. The query param would change when you click run tests and save it. You would still have to check.

Let's think more on this.