Searchable REPL thoughts #382
Comments
|
Filing here some of ideas that came out while chatting about the REPL. Retrieving gistsGists made with the Svelte REPL should contain a We tried using @jvcalderon's gist-client but so far it threw. const GistClient = require("gist-client");
const gistClient = new GistClient();
const GITHUB_TOKEN = "GITHUB_TOKEN";
gistClient
.setToken(GITHUB_TOKEN)
.getAll({
rawContent: true,
filterBy: [
{public: true},
{content: "svelte"},
{since: "2018-11-01T00:00:01Z"}
]
})
.then(gistList => {
console.log(JSON.stringify(gistList))
})
.catch(err => {
console.log(err)
});The Github token shouldn't be required for public Gists but so far it throws if we don't provide a token. EDIT: as of today a simple search (https://gist.github.com/search?q=svelte) shows that there are 232 gists containing the word "svelte". |
Detecting Svelte features in a gistAnother part of the conversation has focused on the idea of retrieving features from gists ( This would let us search by feature, similarly to what has been done in blockbuilder (here @enjalot outlined some very interesting insights about the effort behind that kind of website). @pngwn has written this walker to show how we can retrieve features from compiled templates 😎 . const svelte = require("svelte");
const walk = require("estree-walker").walk;
const compiled = svelte.compile(`
<p class:myClass="condition" on:click="noop()"></p>
{#if condition}
<div>boo</div>
{:else}
<p>Hi</p>
{/if}
<script>
export default {
data() {
return {
condition: true
}
},
methods: {
noop() {}
}
};
</script>
`);
function walky(ast) {
let features = [];
walk( ast, {
leave: function ( node, parent ) {
if (node.type) {
features.push(node.type);
}
if (node.attributes) {
node.attributes.forEach(v => features.push(v.type))
}
}
});
return features;
}
console.log(compiled);
console.log(walky(compiled.ast.html))
In this example:
|
Meta file formatAnother part of the conversation was about the Currently as said that file contains just
Again, having these fields would permit to think about an enhanced/unified search:
|
Version switchThere has been some discussion about the possibility to switch Svelte version while editing the REPL, especially useful while learning how to upgrade to a breaking version.
Should we do this, the meta file would have to change depending on context. |
Gists publishing and meta files storingWe realised that if the interface let us to publish (and unpublish) gists, when a gist goes "Public" we can save its ID and its meta file somewhere. As of now we don't expect a huge amount of gists to be published so probably we can just update a single gist with the contents of all the meta files. This would permity us to easily search by fetching and searching in that central gist in the client memory without using a DB for now. Also, since the Svelte 2 gists have a minimal meta file (not particularly useful for these purposes), we could make so that the REPL saves this additional information only for Svelte version 3 to clearly mark a line between v2 and v3. Users would have to actively update their gists to Svelte 3 using the REPL interface to mark an old gist as searchable (setting it to version 3+ and publishing it). EDIT: this would avoid us the need to search for gists in the future. |
|
I think we can definitely improve the REPL, especially having more examples and making discoverability easier. Searching Gists Feature Tags Versioning Version Switching Other Thoughts I also think I prefer the term 'playground' to 'REPL'. |
Renaming the meta file to
|
@pngwn me too |
Listing and searching own gistsOnce logged in, it would be quite useful to list and/or search our own gists (by title, used Svelte features, etc) directly from the REPL. Searching a user's gists shouldn't be a heavy operation and it would be a matter of filtering those with a working This functionality would help to revisit old tests and eventually turn them into public examples or delete them. Saving a thumbnail of the rendered areaEventually, to help the search, we might think about capturing a thumbnail of the rendered area to be shown while the searching. |
hey all,
I've been thinking a bit about a browsable REPL-structure and I would like to share some thoughts for the upcoming v3 and guide-overhaul.
I discover myself stumpling through unrecognizable bookmark-folders with bad named bookmarks to keep some scripts/examples/best-practises/solutions in mind.
In the meanwhile there are so much, somethimes outdated, that I have to open several to find the right one. In the best case. Most of the time, I'm not able to find what I was looking for.
Wouldn't it make sense for the saved gists to add some search or sort criteria to get/find to the examples the user needs? Kind of what is done currently with the menu.
What could be a structure that makes sense, not distracting with too much overhead or additional administration-expense?
Maybe it's just me using the REPL this way. Maybe it's too much.
But as I notice, also from the repeadetly asked questions over @discord ('how can I do this', 'xy is not working', 'why?', 'how?'), the REPL could, maybe should be one central piece to make svelte a really good dev-experience.
Just a thought.
I know v3 requires all resources.
The text was updated successfully, but these errors were encountered: