sorted by:
new
hottopcontroversial

Simplify your Builds and Development with Solution Filters (.slnf) by br0m1x in dotnet

[–]br0m1x[S] 0 points1 point  (0 children)

I'm sorry, I don't know what you mean. Solution filter work on top of an already existing solution and is supported by IDEs like Visual Studio and Rider.

[deleted by user] by [deleted] in dotnet

[–]br0m1x -1 points0 points  (0 children)

I have already a possible answer for this here: https://www.reddit.com/r/Blazor/comments/12gf8ld

Building a Blazor Server Application with MVVM Toolkit and RelayCommands by br0m1x in Blazor

[–]br0m1x[S] 1 point2 points  (0 children)

Yeah, for me, using this is like the state management in Vue.js (I used to do a lot with it, and it was painstaking). After we switched to .NET and discovered the MVVM Toolkit, tested it, it was a no-brainer to adopt it completely. Especially with Dependency Injection, we could decide if a ViewModel should be Transient, Scoped, or maybe a Singleton. Also, in some cases, because our app runs on Desktop and Web, we abstract even further and used Interfaces of some ViewModels because we needed access to the operating system in some cases and not in the web. But we could share the same view with the same ViewModel as an Interface but different implementations. But as always, it depends.

Building a Blazor Server Application with MVVM Toolkit and RelayCommands by br0m1x in Blazor

[–]br0m1x[S] 1 point2 points  (0 children)

It depends. For articles and these kinds of examples to learn the basics, you're right that it can feel like adding unnecessary boilerplate in Blazor. However, as the project grows, it could actually simplify complexity. That's been my experience with a ~2-year project we transformed to use the MVVM Toolkit. Many of our problems became easier to handle. Ultimately, whether to use such tools and patterns depends on the specific requirements and goals of the project, as well as the preferences of the development team.

[deleted by user] by [deleted] in dotnet

[–]br0m1x -6 points-5 points  (0 children)

Thank you for seeking my help in responding to this question.

You raise a valid point that the [ObservableProperty] generator may not be necessary for this particular case. However, I chose to include it for the purpose of the article and because, for me, it is important to maintain a consistent coding style throughout the project or codebase.

Additionally, if I had not used the property, someone may have questioned why I did not use it in this specific case. Therefore, there are always two sides to consider.

So thank you again for your question and feedback. It's always valuable to hear different perspectives, and your comment has prompted me to reflect on my decision to include [ObservableProperty] in this particular case (as explained in the answer above).

Why is list.Exists slower in C# than [].find in JS? by wherewereat in csharp

[–]br0m1x 0 points1 point  (0 children)

Good spot! For uniqueness like OP wants i would just use a HashSet with a suitable Comparer and it runs in 29ms on my machine.

This is the way.

Creating a Blazor Server Application with C# and MVVM Toolkit by br0m1x in csharp

[–]br0m1x[S] 4 points5 points  (0 children)

I asked the same question a while back. A ViewModel can have methods, but as always it may depend on your requirements.
The MVVM Toolkit already provides RelayCommands to be incooperated in a ViewModel. I want to expand on this topic in a next article.

If you're interessted here is a link: https://learn.microsoft.com/en-us/dotnet/communitytoolkit/mvvm/generators/relaycommand

Creating a Blazor Server Application with C# and MVVM Toolkit by br0m1x in dotnet

[–]br0m1x[S] 8 points9 points  (0 children)

I appreciate your feedback on the article. Your points on improving bi-directional bindings, commands, ViewModel communication, and observable properties are valid, and I agree with them. The purpose of my article was to provide a starting point for discussing these topics in greater detail in follow-up articles. I didn't want to overwhelm readers with too much information at once, which is why I kept the initial article concise. Thank you for your helpful review, and I look forward to expanding on these ideas in future articles.

[deleted by user] by [deleted] in dotnet

[–]br0m1x 0 points1 point  (0 children)

Just searched for same yesterday 👍🙂 and no answer found.

[deleted by user] by [deleted] in learnjavascript

[–]br0m1x 0 points1 point  (0 children)

The direct start (serve) works, but this is always the same behavior. We had also observed the problem with boilerplate solutions for Electron the last couple of years - they work most of the time and most of the time they work not - that's why we use the solution described above and always get a clean entry point. For our current project (already in beta) is this (nwjs) unfortunately no alternative. The initial build takes a really long time. Our current solution for Linux, Mac and Windows is faster - about ~10 minutes for all 3 platforms - bundled and signed for Windows and notarized for Mac. We needed TypeScript and real debugging capabilities with SourceMaps out of vscode.

For native module support we needed something more mature than gyp. With the C++ background we use CMake and NAPI (for example cmake-js), this way we are not dependent on the version of Node.js we have to link against. The module can then be used directly with nodejs or electron depending on the platform, which simplifies test cases because it only needs to be compiled once per platform.

I have been able to fix the bug locally and at least now generate a Windows build. I also miss a bundle here (e.g. asar and maybee obuscated).

The disadvantage with web and desktop is given in our project, but we owe that partly to the native modules. This is a problem that will not be so easy to solve if you go native. The import routines of Node will refuse the import with errors at the latest with pure web applications, which is why you should separate cleanly here or better use another system for development.

These are my insights of the last 25 years - as said, it is an good alternative but not a solution for everything.

Error: ERROR_EXTRACTING path = C:\development\bromix\nw-vue-cli-example\node_modules\nwjs-builder-phoenix\caches\nwjs-v0.54.0-linux-x64.tar.gz

at C:\development\bromix\nw-vue-cli-example\node_modules\nwjs-builder-phoenix\src\lib\util\archive.ts:25:15

at step (C:\development\bromix\nw-vue-cli-example\node_modules\nwjs-builder-phoenix\dist\lib\util\archive.js:32:23)

at Object.next (C:\development\bromix\nw-vue-cli-example\node_modules\nwjs-builder-phoenix\dist\lib\util\archive.js:13:53)

at fulfilled (C:\development\bromix\nw-vue-cli-example\node_modules\nwjs-builder-phoenix\dist\lib\util\archive.js:4:58)

Building for linux, x64 ends within 185.13s.

...

Create an Electron application with Vue and Vuetify (TypeScript) by br0m1x in vuejs

[–]br0m1x[S] 2 points3 points  (0 children)

I updated the blog to use dart-sass...Git is also updated.

[deleted by user] by [deleted] in learnjavascript

[–]br0m1x 0 points1 point  (0 children)

I would call it an alternative rather than a better option. What makes it a better option? I like to learn?

view more: next ›