AMP Playground should automagically import component scripts

[tomayac]

Currently it's a bit burdensome to include component scripts manually. Turns out, @garanj has built a Gulp plugin called amphtml-autoscript that does it automagically. Can we incorporate this (or its logic) into the Playground?

[sebastianbenz]

Yes please 😀

[garanj]

Hi @sebastianbenz ,

Thanks for your advice on start points. I had a go at building and it seems pretty straightforward (even for me!) to hook into the necessary events for a new module. Works nicely.

I've two questions, and would welcome some guidance:

1. I was thinking of subscribing to Validator.EVENT_NEW_VALIDATION_RESULT, and making use of the fact that validation results were already available. If not, possibly Editor.EVENT_INPUT_NEW, but I think really the former.

   In either case, using editor.setSource can cause a loop, as it fires Editor. EVENT_INPUT_NEW, which triggers editorUpdateListener, validation etc.

   I've a couple of options for how to set the text of the editor without causing an event loop. Any preferences on how to do it? One might be a further method in Editor, or adding an optional parameter to setSource indicating whether or not to fire events?

2. I've used your snippet for getting a list of components, and added in getting version numbers. Works great. However, I'm thinking that the client should really not be making this request to GitHub direct, instead either:

   1. An endpoint within Playground that provides the list (and periodically refreshes this with GH)
   2. A list formed as part of the build process

   Do you have a view on either approach? I think GH would probably limit requests, if coming from clients, and this could be a problem, and additionally, the response is needlessly large compared to the list that is created from it. I favour approach 1 above, and wonder if you have views on where this should sit?

Apologies if these seem obvious questions!

[sebastianbenz]

Thanks a lot for looking into this!

1. I think it definitely makes sense to hook into validation results. The loop is tricky, as we'll have to fire a new change event to trigger validation. Do you know what's causing the loop (as it shouldn't happen)? Regarding changing the doc, I think we should introduce a new method to Editor which then delegates to codemirror's built in API: https://codemirror.net/doc/manual.html#replaceRange.
2. I agree, it makes sense to move this server-side.
   • You could extend the current playground backend here (it's implemented in Go though). I'd suggest using a stale-while-revalidate caching strategy and store the results server-side.
   • Another option would be to store and cache the results client-side (e.g. service worker cache or IndexedDB).

[kul3r4]

@sebastianbenz can we close this?

[sebastianbenz]

Yes! Chiara Chiappini <notifications@github.com> schrieb am Mi. 26. Sep. 2018 um 18:45:

…

@sebastianbenz <https://github.com/sebastianbenz> can we close this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1457 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXOOPjFtI-ln4DlRk9V68X_GP5XglFIks5ufC2fgaJpZM4V7_Ot> .