Could we declare multiple <script> and <style> blocks in a svelte file ?

[pierre121]

Describe the problem

I have multiple svelte component that export the same kind of prop ==> type:'type 1'|'type 2'|'type 3'

I'm currently writing the svelte file as such :

<script>(...)</script> // for type=='type 1', type=='type 2', type=='type 3'
{#if type=='type 1'}  
(...)
{:else if type=='type 2'}  
(...)
{:else if type=='type 3'}  
(...)
{/if}  
<style>(...)</style> // for type=='type 1', type=='type 2', type=='type 3'

It'd be ideal if i could write the svelte file like that instead :

<script>(...)</script> // for type=='type 1'
{#if type=='type 1'}  
(...)
<style>(...)</style>  //for type=='type 1'

<script>(...)</script> // for type=='type 2'
{:else if type=='type 2'}
(...)
<style>(...)</style>  //for type=='type 2'

<script>(...)</script> // for type=='type 3'
{:else if type=='type 3'}
(...)
<style>(...)</style>  //for type=='type 3'

{/if}

As @johndeighan reminded us here, JavaScript allows multiple script blocks. His request was closed because his case was too specific, but mine is very general.
Many other cases could also benefit from this ; e.g., when a function is only used once in the html, and the programmer believes that it would be clearer to include this function next to the html, inside <script> tags
In my app i have 51 svelte files, and 7 files i organized in this way(, for short tools, icons, type of moderation msgs, type of statistics, type of menus, parameters, and themes), and i'm not counting the files with a tab bar(, the modlog, the search results, ...), i don't think i would be the only one who would benefit from such feature, if it can be done.

Describe the proposed solution

If it'd lead to too many complications then nevermind, there may be a good reason for getting rid of this useful feature/freedom, but if it can be added i'd like to request it.

Thx !

Importance

nice to have

---

If you want to skip the discussion, i've made a list of advantages and disadvantages that will be edited if i'm aware of any new comment in this thread

[brunnerh]

Please show what you are doing in your script/style/markup, I suspect that there are good ways of organizing the code without requiring multiple scripts/styles. Maybe commonalities can just be extracted to a separate JS file, CSS file or component.

(A change to the way these blocks work seems unlikely to me.)

[pierre121]

Unfortunately it's in french, but here's a short example attached to it(, it's an 8th example in my 51 svelte files that i haven't thought about) : Ouverture.zip

It's an interesting one that i've made these last two days, but even if it's small it needs to work with other files, it's not autonomous, if you want to i can create a more independent component, however you may have simply asked for a random example.

I'm calling the component Ouverture.svelte like that :

<OUVERTURE type='nouvel onglet' nouvelOnglet={créerOnglet('autres', laCommunauté.community.title||laCommunauté.community.name, laCommunauté.community.icon)} 
    <COMMUNAUTÉ instance={instance} bind:cetteCommunauté={laCommunauté} afficherPlus={true} bind:afficherLaCommunauté={afficherLaCommunauté} />
</OUVERTURE> 

Here, <COMMUNAUTÉ/> will be opened in a new tab because type=='nouvel onglet'.

type can be equal to 'nouvelle fenêtre'(, new window), 'info-bulle'(, tooltip), 'tiroirG'(, left drawer), 'tiroirD'(, right drawer), or 'nouvel onglet'(, new tab), so <COMMUNAUTÉ/> will be opened in a new window, or in a tooltip, or a drawer, or a tab, depending on the value of type

Once again, sorry for the file written in french.

I could also find an old version of a very large file of hundreds of lines with more than a dozen type if the problem doesn't seem obvious with such a short file.

(A change to the way these blocks work seems unlikely to me.)

Yep, me too, such big change would be suprising(, well, i.d.k.)

[brunnerh]

This design seems odd to me. The code for the various types seems very independent, why are you not using separate components instead?

I.e. <Window>, <Tab>, <Drawer position="left | right"> & <Tooltip>.

Even if you keep an <Open type="..."> component, it could internally still use separate sub-components instead.

[pierre121]

The first reason, for all files, would be that it makes more sense to put them all in the same file rather than having a folder of multiples files, it's cleaner.

For some files, such as the one with the icons, it's because they may have a different html depending on the type but they keep the same style.
Although, yes, i suppose that i could create multiple components in that case, and use a separate css file.

For other files, such as Ouverture.svelte above, it's because i'd like to let the choice to the user in the settings, who may prefer to open a specific component in a new tab, while other users may prefer to open it in a tooltip.
However, once again, i readily agree with you that i can always create the components <Window>, <Tab>, <Drawer position="left | right"> and <Tooltip>, and call them inside Ouverture.svelte depending on the value of type.

It'd just be more concise/practical to put everything in a file instead of a folder with multiple files.
For example, if i have two types of components creating a dropdown menu, with a (partiallly )different logic and style for each, then i think it'd make more sense to put them both in the same file. But also : they could share some functions, variables, styles, and have a similar structure(, such that it's easy to be helped/"inspired" by the other dropdown menu when working on one of them).
Another similar example would be my file about statistics, with three different categories and a large script. While i could create a folder with three files inside, i'd prefer to keep a single file instead, although it'd be nicer if i could insert its script block above each <canvas>. They share some similar functions in the same file, and it helps to have a quick access to the logic of the other categories.
I could say the same for my file Menu.svelte which contains a different menu if it's a post, a comment, an image, ..., but some options of these menus are shared, so it makes more sense to put them in the same file.
Finally, i don't like to have components with only 10-20 lines, which is why i've put all of them in a single tools.svelte, it's a personal preference once again, but i may not be the only one trying to reduce his number of files.
I'm trying to multiply the examples but it seems that i've just repeated myself four times here.

And it's not only related to files that can be compartimented with a prop such as type ; e.g., while i haven't tested it, i'd like to try to write html interspersed by dozens of script blocks, that'd certainly be a different way of writing/reading code(, i don't like tailwind but some people do, i'd prefer to put style blocks instead at some clear delimitation points of the html).

If requests are only for bugs then sorry for my mistake.

That javascript naturally supports multiple script blocks may not mean that it'd necessarily be easy, but i'm so ignorant that i'm thinking that even if a single script block is necessary then maybe the only change the compiler would have to do is to cut-paste the different content of the script blocks into a single script block, and then continue the process as usual(, as well as adapting the svelte parser, etc.), which is why i.d.k. if such change/feature/improvement would be technically impossible at first sight.

[brunnerh]

The first reason, for all files, would be that it makes more sense to put them all in the same file rather than having a folder of multiples files, it's cleaner.

It may look like that, but it makes it harder to reason about the code and navigate it. Usually many small 10 line functions are preferable to a single 200 line function. Especially when multiple people work on something, it saves lot of time if those 190 lines can be completely ignored if only 10 are actually relevant to the issue at hand.

If requests are only for bugs then sorry for my mistake.

That is not the case, don't worry, but feature requests also need to be challenged.

i.d.k. if such change/feature/improvement would be technically impossible at first sight

Apart from the technical feasibility, a very important question is whether it is a good idea. Even if a feature itself has neutral value, just adding another feature increases the overall complexity of the codebase and increases the risk of bugs and regressions in other areas. So by default, everything is already a net negative.

Given that most people probably would not recommend the approach you are taking to component and file organization, I doubt that there is much demand for this and that it would justify the associated costs. On top of the added complexity, having additional syntax means also that more things need to be documented and potentially taught/learned — more stuff also means more potential for confusion.

So as mentioned, I would go with separate components if the contents are mostly independent, extract shared things into their own CSS/JS files and keep files relatively small. (Also highly recommend navigating components directly via their file names rather than going through the directory tree, having all those small components actually helps navigation when doing this.)

[pierre121]

That is not the case, don't worry, but feature requests also need to be challenged.

(Oh, ok, that's entirely natural then, i just had the first impression that the only argument against this feature was that it was useless because another way existed, now i understand that your point was instead that you don't consider it as desirable/practical as i do)

just adding another feature increases the overall complexity of the codebase

I agree

and increases the risk of bugs and regressions in other areas.

Some features more than others, yes

Given that most people probably would not recommend the approach you are taking to component and file organization, I doubt that there is much demand for this and that it would justify the associated costs

No. Wouldn't you want to have the freedom of writing multiple script and style blocks ? It's an evident advantage, i don't understand how i could lose the argument that such a basic/fundamental amelioration would be useful. Even those who agree with this approach to component and file organization may appreciate to have this liberty/possibility(, e.g. temporarily to avoid frequently scrolling back-and-forth between the html and the script and/or style while adding something new in some cases). I guess ideally the desire of the "Svelte society" should be seeked by a survey, because it'd be hard to debate subjective preferences.
It depends on the situation, but a lot of people never use very long functions while i often prefer them, and i don't like to switch between tabs, i also strongly prefer to put everything on the same line, people are different.

I expected a technical reason, not "We could (easily? )do it, but( the real problem is that) i prefer to have a lot of files and folders rather than a few of them, so you should to", and i guess to be fair i should add that you don't believe it'd be used&useful enough, which i can't agree with or even understand, perhaps could you develop on that if you want to challenge what seems an obvious/undeniable advantage in my eyes ?
Or i guess that you can close the thread if you're not convinced then, or ask for a second advice if you have an hesitation, and thank you for your time anyway,

P.S. : To orientate myself inside a large function/file, i'm using different type of comments with different regular expressions :

• //*... in a dark gray highlighting
• //* ... in light gray
  The function itself is generally under a :
• //!... title in light red
• //! ... title in dark red
  And large zones really distinct are delimitated by :
• //?... in light blue
• //? ... in dark blue
  With that, i have much less difficulties to navigate inside a large file/function, just a random tip for anyone reading this if interested🤷(, i've also like 6 or 7 different types of todos but it's probably more common).

[brunnerh]

Wouldn't you want to have the freedom of writing multiple script and style blocks? It's an evident advantage, and even if you don't, you shouldn't force other people to follow your approach to component and file organization.

Depends. One advantage that frameworks can provide is consistency. If every Svelte codebase is completely different from all others, this hinders collaboration, compatibility and is a cause for confusion. It also makes learning and reading the code harder. Multiple competing syntaxes are generally avoided due to similar problems.

I expected a technical reason, [...]

There might be technical reasons not to do this, but I have not considered that aspect since I am also not too familiar with Svelte's internals and I am not a maintainer. I just suspect that the incurred costs of this are too high to justify it. There of course could be various problems with scoping, hoisting, statement ordering and whatnot.

Since the request for multiple components in single file was rejected (though Svelte 5 will have snippets), I doubt that the maintainer team will like the idea of multiple scripts/styles.

I am not telling you want to like, but you might have make do with the status quo. While I acknowledge that some things are just a personal preference, many things have a measurable impact. E.g. there might be differences in how fast certain code styles can be read. Of course this can come down to familiarity but if most of the world codes a certain way, that probably needs to be taken into account. Your custom comment syntax shows to me that your code style is pretty far removed from the familiar.

Ultimately, frameworks unfortunately can't really please everyone, otherwise they become a mess.

[pierre121]

I'm reopening this subject because i've read that you can't put script and style blocks in a snippet(, shouldn't have lazingly trusted ChatGPT on that one). Since, apparently, you can only put HTML in there, it isn't equivalent to the initial request :/

---

While many people here are in favor of reducing the number of files by having multiple components in a single svelte file(, e.g., or here), there are also many people who are really opposed to the complexification of syntax that will be brought by snippets.
I do not care that much about this complexification, but at the same time, like everyone else here, i do appreciate the focus of Svelte to be as simple as possible.

"My" solution is ultra basic : create a component with the prop "type" and use multiple if..else
I don't think that it'd be a problem, but if you can't put a <script> or <style> block inside an {#if} for some reason(, you can for other tags), then it'd only need to be outside the #if, as such :

<script for type=='type 1'>
{#if type=='type 1'}
{/if}
<style for type=='type 1'> 

<script for type=='type 2'>
{#if type=='type 2'}
{/if}
<style for type=='type 2'>

<script for type=='type 3'>
{#if type=='type 3'}
{/if}
<style for type=='type 3'>

If i'm not mistaken somewhere, and the performances aren't too bad, then we'd have the best of both worlds : no new syntax ; and the possibility of dumping little components in a single svelte file.

It's almost certain that i'm mistaken but i'm asking just in case.

[7nik]

I checked out the Ouverture.svelte and saw four components stuffed up into one file. If multiple cases require barely related logic, markup, and styles, then they should be implemented as separate components. Otherwise, you get messy code, and the fact that you have to use colourful comments only proves this.

Your approach is like organized chaos - it's good for you and only you.

[pierre121]

That's what @brunnerh said : increase your number of files and folders.

However, many people would prefer to put multiple small related components inside a single svelte file, in order to avoid having too many folders and files, that comment is another one.

I don't agree with the apparent "norm" of spreading your code on multiple lines, functions, and files. I'm not the only one to prefer to visually encompass as much as i can without having to do a back and forth and trust my memory.
You're saying that it'd be cleaner to put Ouverture.svelte in a folder with 4 other files. I've zero doubts that it'd be cleaner to keep a single file instead of a folder.
I'd prefer to divide this file into multiple components only if i want to, because i consider it logical, not because being unable to put multiple script and style blocks makes it messy, at least if such feature would be easy to implement and isn't considered simply out of principle.

And if there's a shared logic and/or style i'd have to add even more files inside the folder(, or rely on a single mega .ts and/or .css file for every shared logic/style, which would reduce the number of files but not the number of necessary opened tabs). I don't like switching between tabs and i'm not the only one(, since there's a lot of upvotes in the other request).

[pierre121]

Here's a list of the disadvantages i could think of :

• D.1 : It'll be disorienting/annoying to stumble upon svelte files written with multiple <script> and <style> blocks : That such feature would be optional doesn't change this problem. A solution is expressed in A.1
• D.2 : Long files are a bad practice that should not be encouraged, it'll lead to more errors(, edit : functions with deeply nested code, functions that do too many things at the same time(, violation of single responsibility principle), variables in multiple places separated by miles of code). I don't really understand/'agree with' this point of view, and expressed mine instead in A.2
• D.3 : It'd need work to implement : For the css, i can't see how merging <style> blocks would be a problem, perhaps in some frameworks.
  As for the script, i think that javascript has done most of it when they enabled as many <script> blocks in the html as a user may want(, e.g., they made variables accessible across <script>blocks, took into account the reactivity, most of the statement ordering, ...), but there's certainly still adaptations to make, i can't judge how much. Not only them, but linters and other tools would have to make an even more serious adaptation than usual probably
  • D.3.5. : edit : It'd make the compiler significantly more complex to maintain : If that's the case then it shouldn't be done(, and i'm kinda wondering why they're still doing that in javascript).
• D.4 : It'd also add some time to the compilation(, in order to merge the multiple <script> and <style> blocks), i don't know if having fewer files will have a positive impact though
  • D.4.5 : It may have an impact on the performances ? Since everything will end up in a single javascript file, i.d.k. if the execution of a very big file with too many components(, e.g., with dozens/hundreds of possible values for the prop type,) would be slower, but i don't consider it a disadvantage because the solution is evident, cf. A.4
• D.5 : Backward compatibility : I'm not sure if i understood this problem well enough, if none could ever arise then it may be an advantage, but perhaps that with, e.g., statement ordering, there would be a need to remember possible exceptions for any future versions of Svelte ?
  If this request is seriously considered, then it'd be useful to ask javascript maintainers(, TC39 or related,) if the backward compatibility of their multiple <script> blocks is a frequent problem for them to think about with each new addition.
• D.6 : example given by @7nik .svelte files should be kept short : I have .svelte files larger than 40-50KB, and agree that multiple <script> and <style> blocks aren't useful below 10KB. Since the latter is how most people code, this feature wouldn't be considered useful by them. A partial counterpoint is presented in A.6

And here's a list of the advantages i could think of :

• A.1 : The problem of stumbling upon svelte files written with multiple <script> and <style> blocks : This wouldn't arise in a working group(, with defined rules), but when fetching files outside. If it becomes a problem, then it'd mean that this feature was a very popular addition, and packages/extensions will probably appear in order to transform the code(, since Svelte is opensource they'll have done all the work necessary to enable them to merge the <script> and <style> blocks)
• A.2 : Long files aren't necessarily a bad practice and should be tolerated : Contrary to what D.2 claims, my personal experience is that mistakes are harder to find when multiplying files(, and functions). I also dislike deeply nested code, rarely don't follow the single responsibility principle, and variables spread across files/functions aren't that much easier to read than when separated by miles of code(, even if i agree that it should be avoided[1]). If one disagrees, you could eventually add in the documentation that large files are allowed but not recommended(, even if i personally prefer them), and it'd be up to the responsibility of the programmer.
• A.3 : No new syntax, this may be the most important point. It adds flexibility without complexity
• A.4 : It'd now be much easier to have multiple svelte components in a single file(, with a type prop and if..else statement in the html) : I've expressed in the first comment how it can be done with a prop type and if..else statement depending on the value of type.
  It feels logical/appropriate to have multiple components in a file if they're related enough, we could more easily take an inspiration of the other component(, or statistics, or menu, ...,), and sometimes they share the same functions and/or style.
  Some applications have more than a thousand files, and some frameworks forces their users to have multiple files. It's worth adding that Svelte is liked because everything is in a single .svelte file, the number of files/tabs in the /src folder matter.
  As for the possible problems of performance for large files : if necessary, then such files would have to be divided and kept reasonably large, with a delay inferior to 100ms compared to having a file for each component(, past a certain point the gains would have to be negligible). Tests are usually done anyway, so if a programmer/team choose to keep a large file they'll have considered the pros and cons.
  • A.4.5 : It'd also be much easier to have a long page in the same file(, no need for a type prop and if..else statements here) : If someone wants to have a single file per page, then a long page could be divided into compartments with their own <script> and <style> block.
    To extend on this, for instance, people use Tailwind CSS because they don't like to scroll back and forth between the html and the css. It'd be even better than tailwind, i.m.h.o., if we could keep the html tags clean/readable, with the css injected at a logical separation between two parts of the html(, especially if you write the css on a single line).
    Some frameworks or languages tried to merge the script and style in the same place/language to avoid scrolling back and forth(, i prefer Svelte to Kotlin though), this would be an intermediary between keeping a clean/readable code with clear distinctions, and having everything at the same place.
• A.5 : Even those who want to keep a single <script> and <style> block could benefit from this feature : For example, to temporarily stay close to the html while adding a new function or a new style(, to avoid scrolling back and forth once again, with each time the need to find where you were initially, as well as remembering the html structure and class/id names when working in the style and script). The only inconvenient would be to have to put it back in its original place when the test/implementation is ended. Or one may prefer to have multiple files, but still find desirable to temporarily compartmentalize a long file until it's long enough to divide it.
• A.6 : It'd (only )be useful for long .svelte files : One of the reason why people don't code in large(, 40-50KB,) svelte files is because that's not how we learned in school and how we code at work. Another may be the same as mine : because the back-and-forth scrolling between the script and the html, or the html and the style, is kinda annoying(, but still less than the back-and-forth switching between tabs). @7nik's example made me realize more clearly that multiple <script> and <style> blocks wouldn't be useful for him, but it'd be useful for larger .svelte files.

---

I've certainly forgotten a lot of advantages and disadvantages.
These lists will be edited if there's any comment posted below that wants to add elements to either of them.

---

Notes :

[1] : A practice could be to have a <script> block at the top of the file for the script that concerns the whole file, and to only declare variables/functions in the <script> block for each compartment if they're related to that compartment.
And if these declarations too frequently include the same 2(/3/..) compartments, then this compartmentalization 'should probably be done differently'/'isn't logical enough'. It'd still be less back-and-forth scrolling(, and/or back-and-forth switching between files/tabs,) than it is currently.

[7nik]

A.1 Many projects were started as pet projects, and then other people came to fix something or add a feature. The more code follows common and good practices, the easier it is for other people to join; otherwise, they may even give up on joining.

A.2 The file size (number of LoC) isn't the problem, but rather such files often contain smelly code: functions with deeply nested code, functions that do too many things at the same time (violation of single responsibility principle), use variables in multiple places separated by miles of code.

D.3 Of course, it's doable; you can even do it yourself with your own preprocessor.
A.3 Nope, you cannot do it without adding a new syntax to differentiate the scripts, styles and markups.

D.4 I doubt it will have a noticeable impact, but it may make the compiler significantly more complex.
A.4 If you know that a bug happens when type="foo" will go to the section/file that is responsible for it. And the less the file is, the less the code related to the bug.
A.4.5 It's faster to write class="flex" than class="my-selector" + .my-selector { display: flex; } in another place and, yeah, faster and easier to read. But the same won't work with JS - you cannot shorten it. There are multiple ways to reduce scrolling:

1. fold the blocks in between;
2. open the same file in two panes;
3. move some code into a separate file(s) + names of functions and components tell you what the code does.

---

I have an example I've written: sort of a different type of post - they share the frame but are very different inside. A clean, straightforward, and understandable code. Cramping it into a single file, will turn this into a total mess.

[pierre121]

A.1 Many projects were started as pet projects, and then other people came to fix something or add a feature. The more code follows common and good practices, the easier it is for other people to join; otherwise, they may even give up on joining.

A very good addition, do you believe it was satisfyingly answered in « This wouldn't arise in a working group(, with defined rules) », with "working group" defined as the opensource project ? Or do you feel that this point isn't answered in the lists above ?

To develop on this :
If pet projects don't follow common practices, and people say that they won't join unless this project conforms to the norm, it'll be up to the maintainer if s.he takes the risk of not following them, and not having people join as a consequence.
Similarly, if a group decides that having a single <script> and <style> block shouldn't be the rule, people will have to conform, common practices are quite a large set of rules, so it'd be another variable(, which will only become a problem if this feature is popular enough).
While my personal beliefs are irrelevant(, i can't know for certain), i believe that it wouldn't be considered annoying in all cases, Some files can be more naturally compartmentalized, it wouldn't be hard to read/'adapt to' them, and could even be appreciated compared to a single <script> and <style> block as it would avoid unnecessary scrolling.
Perhaps that the norm may evolve, as norms do, that following the common practices wouldn't mean creating as many small files as possible in the future.

A.2 The file size (number of LoC) isn't the problem, but rather such files often contain smelly code: functions with deeply nested code, functions that do too many things at the same time (violation of single responsibility principle), use variables in multiple places separated by miles of code.

I've updated the D.2 and A.2 as a consequence, please tell me what you think of the answer if you feel inclined to

A.3 Nope, you cannot do it without adding a new syntax to differentiate the scripts, styles and markups.

I don't understand this point, why would you need to differentiate them ?
I've expressed a solution with only the prop type and if..else statements in the first comment. And you wouldn't even need any of that for long files.

D.4 I doubt it will have a noticeable impact, but it may make the compiler significantly more complex.

I've edited the D.3 by adding a D.3.5

A.4 If you know that a bug happens when type="foo", you will go to the section/file that is responsible for it.

A simple ctrl-f will lead you to the if..else statement delimiting this compartment

And the less the file is, the less the code related to the bug.

If it's in the case of a file compartmentalized into multiple svelte components, then their lines of code will be independent from each other(, similarly to Ouverture.svelte).

But if you were saying that a bug in one svelte component could affect the rest : the bug will only appear if the value of type correspond to the if..else branch containing this bug.

And if you were saying that having multiple files related to each other will reduce the number of bugs(, e.g., by having <Window>, <Tab>, <Drawer position="left | right"> and <Tooltip>, and call them inside Ouverture.svelte), i'd say that it wouldn't change much, since in your case the bug could still be spread across files(, e.g., if it appears in <Tooltip>, the cause could be in Ouverture.svelte), and in mine it could be spread across this single file(, once again if it's compartmentalized then it's not harder to find, the whole point is to limit the back-and-forth scrolling after all, and the tabs switching).

A.4.5 It's faster to write class="flex" than class="my-selector" + .my-selector { display: flex; } in another place and, yeah, faster and easier to read. But the same won't work with JS - you cannot shorten it.

It's subjective, but i don't agree, except perhaps with short examples like class="flex". Tailwind is known for cluttering the markups/html, at least i personally don't think it has its place in the html. Do you want me to add this argument in one of the list above ? I'm not sure how i would formulate it.
I don't understand your part with the script though, my example would be that you have a page with a part that displays, e.g., a slideshow of pictures, and you're using a specific logic(, and a specific style,) to display it. Then i think it'd be nice to read the script&style part only when you've arrived at the compartment concerned by them, without the need to scroll back and forth in order to progressively understand the code.

---

There are multiple ways to reduce scrolling:

fold the blocks in between;

That's very annoying, i've created a keyboard shortcut last year to do that, but barely used it. It's a nice advice, but you're constantly forgetting what has been folded or not, and you spend your time folding stuff, with the need to remember where everything is. Good advice though, some people probably use that instead of scrolling.

open the same file in two panes;

And lose the possibility of having long lines.

move some code into a separate file(s) + names of functions and components tell you what the code does.

And you'll have to switch between mutiple tabs :/

---

I have an example I've written: sort of a different type of post - they share the frame but are very different inside. A clean, straightforward, and understandable code. Cramping it into a single file, will turn this into a total mess.

It ultimately depends of the complexity of your components, but even if it was complex(, well, reasonably of course), it wouldn't be a problem if you have colored comments that visually delimits your if..else compartments, scrolling up and down would be the exact same as switching tabs.
I haven't looked at all the files in the activity folder, but since ActivityBase.svelte is the largest one, my personal preference would have been to put all of them in Activity.svelte because they appear simple/short enough.
My largest .ts file is 127KB long(, for every type of call to the a.p.i.), and my largest .svelte file is 62KB(, it's the component when you're writing a text, i had to switch from VSCode to SublimeText because the extension "Svelte for VSCode" stopped rendering the semantic token types past a certain file size). It's admittedly a bit long but i'd like to go even higher, i don't think that it's objectively bad and good, it's more about personal preferences, and i may certainly be forced to conform to the norm one day(, if it doesn't change in my direction).
But i agree that in some cases it's indeed better to do like you, that's also what i'm doing in my app, e.g., i'll have a component for framing the list of posts, and another component for a post(, and similarly for the comments), even if the component framing the list of posts and comments doesn't necessarily have a lot of lines(, although complexity/length is still usually the most important factor for me to decide if i'm dividing the component or not).
(It makes me think of tabs : You may also avoid creating multiple components for each of the tabs of a page with a tab bar, preferring instead to have multiple if..else while staying inside the same svelte file. Well, it'd depend of the complexity of each tab once again, but they're usually similar anyway)
(B.t.w., i've heard about <script context="module"> but not about <svelte:options immutable/>, 'twas interesting, i shouldn't postpone the tutorials forever)

---

Once again, please correct me if you feel inclined to, but in any case, thank you very much for having engaged with this request thus far.

[7nik]

A.1 Many projects were started as pet projects, and then other people came to fix something or add a feature. The more code follows common and good practices, the easier it is for other people to join; otherwise, they may even give up on joining.

A very good addition, do you believe it was satisfyingly answered in « This wouldn't arise in a working group(, with defined rules) », with "working group" defined as the opensource project ? Or do you feel that this point isn't answered in the lists above ?

I mean pet projects with initially a single developer.

I've updated the D.2 and A.2 as a consequence, please tell me what you think of the answer if you feel inclined to

It sounds like "I don't write a bad code". But looking at the Ouverture, I cannot name it a good code at all:

• many lines are over 200 characters long;
• mixing snake and kebab naming;
• the code doesn't follow common code style at all (google "javascript google/mozilla/microsoft code style");
• using addEventListeners instead of on:event;
• if you want to share you code or let people to contribute to it, you should use English in the code;
• I'm too lazy to translate comments, but I'd say there are too many of them.

A.3 Nope, you cannot do it without adding a new syntax to differentiate the scripts, styles and markups.

I don't understand this point, why would you need to differentiate them ?

<script for type=='type 1'> or whatever it will be is a new syntax.

A simple ctrl-f will lead you to the if..else statement delimiting this compartment

You can quickly go to any file with ctrl+p

e.g., a slideshow of pictures, and you're using a specific logic(, and a specific style,) to display it. Then i think it'd be nice to read the script&style part only when you've arrived at the compartment concerned by them, without the need to scroll back and forth in order to progressively understand the code.

The slideshow must definitely be a component in this case. It looks like you don't understand what the single responsibility principle means or why it is used.

open the same file in two panes;

And lose the possibility of having long lines.

you can split vertically as well

move some code into a separate file(s) + names of functions and components tell you what the code does.

And you'll have to switch between mutiple tabs :/

I'd say I rarely switch between "sibling" components - I more often go to child or parent components.

my largest .svelte file is 62KB(, it's the component when you're writing a text, [...] It's admittedly a bit long but i'd like to go even higher, i don't think that it's objectively bad and good, it's more about personal preferences, and i may certainly be forced to conform to the norm one day(, if it doesn't change in my direction).

My personal opinion: 500+ LoC - you really should think about splitting the component; 1000+ LoC - there is definitely something wrong.

62KB svelte file - no wonder you have trouble with intense scrolling; here, even minimap won't help.

[pierre121]

I don't think i have much to add to your comment, so i'll keep it brief( for once) :

looking at the Ouverture, I cannot name it a good code at all

Certainly me neither(, it was only a 2-days old file after all), but not always for the same reasons(, b.t.w., if it wasn't for openNewPage(), i'm usually putting short functions only used once, like closeNewPage(), directly in the on:click of the html, but i agree with the naming, and also with the on:event(, i've used on:pointerdown&Co in other files, so i should have stopped this habit of putting them in the onMount, thx)).
If i want to join a group i'll have to adapt whenever Prettier can't compensate.

<script for type=='type 1'> or whatever it will be is a new syntax.

Why would you ? (edit : i understood a bit too late what he meant, and edited the first comment to be clearer)
If a new syntax is needed for performances issues, the script tag can either : be put inside the {#if} block to avoid its rendering ; or it cannot, but it could be considered that «a delay inferior to 100ms compared to having a file for each component» is acceptable(, cf. the question of performances in A.4).

The slideshow must definitely be a component in this case. It looks like you don't understand what the single responsibility principle means or why it is used.

We both believe that we follow this principle, even if i agree that your interpretation is stricter than mine(, probably for functions as well). There's always a granularity that is subjective, you can theoretically make a different function for every single operation for instance.
If you think that it's a good thing then great, don't stop, i've tested this way of doing(, it's omnipresent i can't miss it), but don't like it.

you can split vertically as well

Any solution with multiple panels will make me lose the possibility of visually encompassing as much as i can, but i understand why programmers have multiple(&large) screens in order to avoid/limit such loss.

[pierre121]

Since Svelte 5 already implemented nested <style> elements, and that snippets cancelled a large part of my argument in favor of a single large file with if..else for excessively small svelte components, and primarily because it seems fair to assume in retrospect that multiple <script> blocks will complicate the implementation of new features and require a supervision of the many different cases of interactions, and also because it would probably not be useful for many persons anyway(, and i just have to scroll or divide the window in two), i'm closing this request, it's not worth the problems.