You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
inform the app developer(s) to make sure that they are not using precompiled UI components, and
inform the component developer(s) to have precompiled components ready to be used by their dependents/consumers.
Precompiled components should only be compiled when/while testing the package itself.
somewhere prominently visible in the docs.
Why would this be beneficial, and who would benefit from this solution?
In those issues mentioned above, they both discuss about consuming third-party component libraries; issue A discusses more general components such as a UI library, and issue B deals with branching components/blocks (e.g. #if, #await, and routers/carousels, and possibly iteration/#each blocks, which are used in almost every Svelte library you can think of). These alone could hinder the practicality and extensibility/modularity of the framework. With the aforementioned information, component devs are aware of how they they ship their components, and make it easier for app devs to import and use an external component without having to worry if their app will break or not (lots of devs are tired of looking at nasty error logs btw).
The text was updated successfully, but these errors were encountered:
What about adding to the documentation the info that if you want to use a pre-bundled svelte component in another svelte component you need to have the svelte internals shared? Or is it still an unsupported way?
What needs discussing?
I would like to suggest some new docs about developing Svelte components.
Why is this important?
Since developing my app, I've ran into two issues that happened one after the other, which both are connected to two different issues.
root
property may throw errors svelte#6584, which I was able to fix by downgrading tosvelte@^3.39.0
, but led to ⬇️How can this be solved?
Put something that would:
somewhere prominently visible in the docs.
Why would this be beneficial, and who would benefit from this solution?
In those issues mentioned above, they both discuss about consuming third-party component libraries; issue A discusses more general components such as a UI library, and issue B deals with branching components/blocks (e.g.
#if
,#await
, and routers/carousels, and possibly iteration/#each
blocks, which are used in almost every Svelte library you can think of). These alone could hinder the practicality and extensibility/modularity of the framework. With the aforementioned information, component devs are aware of how they they ship their components, and make it easier for app devs to import and use an external component without having to worry if their app will break or not (lots of devs are tired of looking at nasty error logs btw).The text was updated successfully, but these errors were encountered: