format VS vanilla-todo

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.

Thanks for this, gives my intuition some words to back it up!

I find especially compelling how the author separates concrete problems like reconciliation (hard to argue against) from the abstract principle of "everything should be a component" (can be argued more easily IMO).

Shamelessly plugging https://github.com/morris/vanilla-todo here; in this try-hard-to-stay-vanilla case study there are similar conclusions: Reconciliation is hard, CSS global namespace is problematic, etc. - I also did not use web components, but could not explain/justify that decision well (until now!).

A few years back I stumbled into something a bit more complex, still done in pure js, just for the hell of it: https://github.com/morris/vanilla-todo

And then wrote my own version, with code a lot closer to modern react, with undo/redo and other niceties - https://github.com/ivank/vanilla-teuxdeux

And what I leaned is that is astonishingly easy to write code that would be understandable to people coming from the redux crowd. Maybe that’s because redux is just such a simple concept in and off itself - a glorified switch on a big object. And it’s also quite easy to hack a simple version of vdom to make it all work.

What’s missing from all those vanilla js efforts though turned out to be testability. There is a ton of code in the modern js world just to allow you to mock/test your components, and thats for me the real tragedy of vanilla js.

I have no idea why W3C crowd have not invested into standardizing js tests in all these years…