format VS observable

C# has https://github.com/dotnet/format but because C# is, well, not JS, the importance of linting is far less significant. Instead, there are hundreds of out-of-box analyzers that highlight problematic patterns or likely mistakes in the code and there are even more that you can enable through extensions (like Roslynator) or through packages that are 'dotnet add package' away.

On the package management - it couldn't be more different between Java and C# and it's incorrect to compare the two. .NET has few if any issues of the former.

In my project, I incorporated a source code formatter provided by the dotnet framework. I also added .editorconfig file to the root directory of my project. This file defines formatting rules, such as indent style and indent size, ensuring consistency throughout the codebase.

However: It would appear that dotnet has a lot of extension values for editorconfig - does Rider support all of those? Some of those? Is there documentation of any extension?

Like this post explains: https://github.com/dotnet/format/issues/879

Dotnet Format

Oh, I'm using .net format. https://github.com/dotnet/format . I will take a look at csharpier to compare both :)

- dotnet format but this is not a linter I think?

Para formatar seu código instale o dotnet format e execute o seguinte comando:

dotnet format does not break lines when they get too long, or collapse lines if they are too short and could be fit on the same line. See https://github.com/dotnet/format/issues/246. Another way to say it - no matter where you put linebreaks in a given code file, csharpier will produce the same output. dotnet format would produce a different output based on where current line breaks exist.

> especially since Observables have been widely available and actively worked on for a long time, without seeing wide adoption

Take a look at "Userland libraries" section [0] of the proposal (almost certainly written by Ben). He argues that observables get reinvented in the userland in various libraries over and over again. It is a primitive, like a Promise, only better.

[0] - https://github.com/WICG/observable?tab=readme-ov-file#userla...

Perhaps this falls into the repetitive boilerplate category you referred to, but if you want framework-agnostic domain objects that still work well with Svelte, create your own using the observer pattern.

Create an object with a subscribe method and whatever other methods make sense for updating its state. Svelte will treat it like one of its stores, and it will work with the $ syntax. It can be used with React via its `useSyncExternalStore` hook. It can be used with SolidJS via its `from` utility.

If you don't want to handle the set-up boilerplate, you could use another library like Effector or RxJS, but of course, that means another dependency. There is a gradual move to make something like this a part of the platform[1], but who knows when or if it will land.

[1] https://github.com/domfarolino/observable