docs(Standards): Add initial Svelte standards#470
Conversation
jmuzina
added
Review: Code needed
Documentation 📝
There was a problem hiding this comment.
Pull request overview
Adds an initial Svelte standards reference document to align Svelte component development practices with the existing “pragma standards” documentation set.
Changes:
- Introduces
STANDARDS_FOR_SVELTE.mdwith Svelte-specific guidelines (purity, effects, refs, progressive enhancement). - Documents composition patterns (subcomponents, snippets, attachments, reactivity boundaries, stable IDs).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
steciuk
left a comment
steciuk
left a comment
There was a problem hiding this comment.
Left a couple suggestions.
Thank you so much for this, Julie!
mariadias143
left a comment
mariadias143
left a comment
There was a problem hiding this comment.
Not really well versed in Svelte so I only have some pointers on file structure. I think overall the doc is well aligned with the existing docs in this folder. It could be interesting to take a look at the code standards repo, I think we would possibly like to move to there (@advl correct me if I'm wrong). But I see this as a good starting point already 🥳
| > <OptionsPanel {groups} submitLabel="Save" /> | ||
| > ``` | ||
|
|
||
| ### Snippets for positioning, subcomponents for encapsulation (`svelte/composition/snippets-vs-subcomponents`) |
There was a problem hiding this comment.
@steciuk it would be useful to include an example the highlights the distinction between snippets and sub components as this one is an important rule but also a bit sophisticated WDYT?
There was a problem hiding this comment.
What exactly would you like to capture in such example?
There was a problem hiding this comment.
When a developer is designing a component API deciding between make a component that accepts sub components vs snippet. technically it is possible to achieve encapsulation with both patterns but this document already anticpates this and explain the preference depending on the situation.
However I think we lack examples showcasing the difference in choice between these two patterns to make it easier to understand.
jmuzina
force-pushed
the
svelte-standards
branch
from
4cbf3a4 to
f6da02c
Compare
|
Can we move this to the https://github.com/canonical/code-standards repo ? |
Sure, I can. Do I need to write the standard in ttl and then run this script to generate markdown? |
jmuzina
force-pushed
the
svelte-standards
branch
from
02801ce to
570b97b
Compare
|
Closed to pursue the conversation on the code-standards repo |
Done
Ports the LUI code practices to markdown standards, following the conventions used in the other pragma standards.
There are some standards in the LUI doc that are closer to generic coding/styling/storybook standards, which I have omitted here. If desired, those should be handled separately.
PR readiness check
Feature 🎁,Breaking Change 💣,Bug 🐛,Documentation 📝,Maintenance 🔨.package.json:check,check:fix, andtest.buildto build the package for development or distribution,build:allto build all artifacts. See CONTRIBUTING.md for details.