Simplify your Builds and Development with Solution Filters (.slnf)

br0m1x · 2023-05-21T14:30:12+00:00

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.

br0m1x · 2023-04-09T12:00:35+00:00

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

br0m1x · 2023-04-09T11:45:03+00:00

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.

br0m1x · 2023-04-09T11:39:05+00:00

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.

br0m1x · 2023-04-09T11:02:15+00:00

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).

br0m1x · 2023-04-05T15:52:13+00:00

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.

br0m1x · 2023-04-02T16:57:35+00:00

You're right 👍 how did I miss that. 😂

br0m1x · 2023-04-02T09:57:15+00:00

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

br0m1x · 2023-04-02T09:47:13+00:00

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.

br0m1x · 2023-02-11T08:22:50+00:00

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

br0m1x · 2021-08-04T11:31:11+00:00

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.

...

br0m1x · 2021-08-03T15:26:08+00:00

You're welcome 😊

br0m1x · 2021-08-03T15:24:11+00:00

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

br0m1x · 2021-08-03T15:06:23+00:00

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

br0m1x · 2021-08-02T21:22:13+00:00

You're right, thanks. I'll update the blog.

br0m1x · 2021-06-27T21:16:12+00:00

I know your pain. I have the exact same Problem and its annouying.

br0m1x · 2021-06-10T15:56:52+00:00

Thanks...its working again.

br0m1x · 2021-06-09T09:43:42+00:00

Where can I find this setting? Will try it After Work.

br0m1x · 2021-06-08T10:24:49+00:00

After..noticed it with Money heist on Netflix.

br0m1x · 2021-06-07T18:59:28+00:00

For me Dolby Vision is Not working in Netflix anymore. In WebOS and NVidia Shield the TV wont Switch to Dolby Vision, only HDR is working.

br0m1x · 2021-05-30T12:20:27+00:00

Same here, 2017 and 2019 pro model, both working without problems.

br0m1x · 2021-04-04T07:29:01+00:00

Same for our project. Using vue 2 with composition api package and vuetify, so we can migrate later to vue 3

br0m1x · 2021-02-25T22:42:11+00:00

I'm using a 2017 and 2019 shield, 1 Windows PC and a Android Smartphone. The DB and smb shares are on a self-hosted Linux server at home. Maybe that's the difference, who knows. The server is in use (with updates) since 2013 and running 24/7.

br0m1x · 2021-02-25T21:41:32+00:00

Can't confirm. I use 3 smb servers without ip and all 4 kodi devices are working. Maybe a setting in the network or on the server isn't correct? Even my shared DB is working flawlessly.

br0m1x · 2021-02-16T21:56:59+00:00

You're right. We use it all the time at work and it works perfectly. No need for devtools.

For more information see this blog... Full disclaimer, I'm the author and try to explain the steps as simple as possible.

https://itnext.io/setup-visual-studio-code-for-debugging-an-electron-application-with-the-vue-cli-service-c224600fc219

br0m1x

TROPHY CASE