-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose runtime types in Svelte #4891
Comments
This would be awesome. VS Code recently introduced a contribution point using a standard Custom Data schema that can be shipped alongside components and automatically picked up by LSP aware tools: https://github.com/microsoft/vscode-custom-data Which you could fetch from github/unpkg and it would look like this: https://raw.githubusercontent.com/mavoweb/mavo.io/master/docs/index.json There are also already some awesome tools being built that even work standalone in the browser. https://runem.github.io/web-component-analyzer/?format=json2 To distribute components with type info in the REPL I have been curious if we could potentially preprocess a custom "types/JS Doc" comment block on each component and store the static data in a standalone json file that could be be used as a makeshift runtime type system. Not sure if that's feasible though, or if anyone else would even find it useful. . |
Came across this thread while looking for information on how to create svelte components at runtime (dynamically from memory). May be it is answered elsewhere, but could not find much information - is it possible to create a svelt component completely at runtime (without having to save it to files, or read from files)? That is:
Any example of this would be great. (All the examples available in the docs showcase a "static / manual compilation" option, where as I am looking for dynamic/runtime compilation example, to create and load the svelte component on the fly in the browser page) |
Check out the code for the REPL itself, specifically https://github.com/sveltejs/svelte-repl/blob/a98ab3a4fa8af8646314a2517510cafe6ac47006/src/Output/Viewer.svelte#L88. It runs the svelte compiler and rollup in the browser as workers. My understanding is the rollup generated dom code gets passed to the eval method on the ReplProxy class which is used by the Viewer component to display the result (linked above). @AlexxNB posted a repl link to a trimmed down version on discord a while ago: https://svelte.dev/repl/eefc5b3e2311457693f153dcdf3ece2f?version=3.19.2 Another option is to lazy load a component (i.e. the compiler output) and pass the constructor to |
Thank you @mjgartendev Will look into the docs suggested. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Closing as inactive - it's highly unlikely we will ever do something like this |
Visual editors
@Rich-Harris has often talked about more visual ways of creating applications. Flow editors are a great way of doing this as are tools like FrameX.
However in order to have great tools that know what can connect to what we need to expose types at runtime. Normally this information is thrown away by the compiler. But because Svelte is a compiler framework I think (with TypeScript landing soon) we should have a standard way of making type information available at runtime if requested.
One way might be to have the Svelte compiler recognise a new extension e.g.
.runtime-types
.This would tell the Svelte complier to turn the
Coord3dType
into a JS object that can be imported from another .js or .svelte file and used to tag a store so subscribers know what to expect. It may also be helpful to have a compiler option that includes runtime type information in components describing their props at runtime.If this is built into the Svelte compiler then we can establish unified ecosystem of Svelte components and stores that can talk to each other at runtime. These can then be snapped together in visual editors and flow editors. If you combine this with dynamic imports from IPFS based CDNs you can then have applications that auto suggest stores and components based on the type of inputs and outputs you are working with for totally open-ended applications.
Inspiration
eth.build
https://youtu.be/30pa790tIIA
Evolving the Visual Programming Environment with React at react-europe 2016
https://youtu.be/WjJdaDXN5Vs?t=729
The text was updated successfully, but these errors were encountered: