.. I'm new to ReactiveUI ..
trying to use ReactiveUI.Blazor .. in Blazor Server Side
.. it has been released but I can't see any examples in the solution
https://github.com/reactiveui/ReactiveUI/tree/master/src/ReactiveUI.Blazor
The only example I can find of Blazor with ReactiveUI
is https://github.com/Nethereum/NethereumBlazor and it's just using ReactiveUI .. not ReactiveUI.Blazor
Any one using ReactiveUI.Blazor ?
cheers in advance
Stu
ReactiveUI is never finished, but there are working samples for Blazor Server-Side (which is now released as of AspNetCore 3.1) and also working samples for Blazor Hosted and Blazor Client models in the ReactiveUI.Samples repository.
You can find the direct link here
TLDR: I had an amazing experience working with Reactive.Blazor in a WASM Blazor application and can absolutely recommend using it.
I used ReactiveUI.Blazor together with Blazorise in platform for managing offers in a more structured way to perform estimates based on the structured (meta)data of the offers.
I used the WASM version of Blazor and my experience was very good. Reactive functional programming (FRP) works well in React and Angular so it seemed like a good fit for Blazor as well.
My review:
The setup was pretty easy. I took a few notes from this arcticle and the code behind it.
I used DynamicData as well, which for me is somehow already part of the whole ReactiveUI stack. It fit very well into the whole application layout, although most of the components in Blazorise do not support the appropriate listeners for collection changes - there you need to support a bit with your code. I absolutely recommend using DynamicData as proxy/cache for your APIs though - state management has never been easier.
The easy form validation, which was a near natural fit for the Blazorise components was for me one of the major selling points - because I rely heavily on dynamic forms.
I am not too happy with the routing and IoC approaches yet. I am used to Autofac for most of my development, which I could easily use my services although for my views and viewmodels I had to rely on a service locator pattern (with Splat backed by Autofac).
Related
I have some Android development experience along with React.js. I'm working on a new mobile project and I haven't been sold entirely on either framework yet.
I'm thinking about using the NativeScript framework for its maturity and because it has more libraries with the functionality that I need but I'd like to design my views in a manner similar to ReactJS. I know I could write my own modules for ReactNative but that would require then I'd have to write modules for both Android and iOS. I'd like to avoid that if I could.
I was thinking about importing the necessary ReactNative libraries into a NativeScript project and then being able to write views in a way similar to ReactNative but still using NativeScript.
Is this doable?
Not sure about your exact question. I did just see an integration between Preact and NativeScript you may be interested in. Take a look here: https://github.com/staydecent/nativescript-preact
I believe that repo is in the early stages, but if enough people want something similar, it'll get worked on faster.
Using React Native in NativeScript is not the right approach, either of it are not built to work together and wouldn't work due to architectural reasons. Here is an NativeScript official comparison of these two.
Both are built for solving same problem (building native apps using JS, without webview hybrid app approach) by trans-compiling XML based view layer(which both these framework has its own syntax and so cant be shared) to build Native UI.
Said that view layer has its own syntax for both and cant be shared, model and controller layer cant be shared as well, due to the fact that NativeScript has few things packed as part of the application package, like JavaScript runtime, c++ and Java API layer which helps in exposing all the Native API without the need for any explicit native API wrapper we have in ReactNative.
React Native have platform specific UI components as well as hardware capabilities, which is not the case with NativeScript. Offcouse, that comes with the cost of a fatter app package size(50+MB) compared to <10MB for ReactNative. More on ReactNative vs NativeScript comparison here.
I'm not a developer myself, but my company develops and supports a large web application for insurance brokers.
Since way back we've been using ExtJS 3.x and as we went further the harder it got to migrate from 3.x to 4 and now to ExtJS 5. Due to the structure of the application and demands from out customers we cannot afford to freeze development and focus on refactoring our interfaces.
But we still want to use the benefits and functionality of the ExtJS 5.
My question is - is it possible to use both versions of the framework in the same application? For example, developing new grids and modules with ExtJS 5 and gradually migrating existing forms.
Did anybody have this sort of experience? Or is it plain nonsense and will never work?
Thanks to everyone in advance.
I find this question very interesting. I had a similar challenge, when I had to migrate our in house app from legacy Jxlib to ExtJs4. Putting my experience together with #Lolo's answer here is what I can advice:
Build on a new solid foundation. You could be tempted to keep your app in ExtJs 3.0 and start grafting new ExtJs 5.0 components on it. If you really want to take advantage of all the new features of ExtJs 5.0, you should start off with a clean, simple MVC app in ExtJs 5.0, that could be as little as the main window and the main menu. You could then bind all existing menu entries to the existing ExtJs 3.0 code. This will allow you to start with a really clean thing, keeping all the old functionality, without rewriting the code, and allow you to develop all new features with clean ExtJs 5.0 code that follows current best practice recommendations.
You will face two stumbling blocks:
You have to separate the namespaces in Javascript and CSS. Here also, I would advice to change the prefixes for ExtJs 3.0, and not for Ext 5.0 (I ignore if ExtJs 5.0 includes a sandbox file). The reason behind is that all your new ExtJs 5.0 code will be standard compatible, while only the old legacy code becomes incompatible (what it is anyway already). This will represent some code refactoring though, because you would need to replace all Ext. occurrencies in all your code with Ext3. or similar (the same applies to CSS, but will be much less work). I hope for you, that ExtJs 3.0 has a sandbox version, because I think refactoring their code would be a lot of work (but not impossible).
A major feature of ExtJs 5.0 (as already for version 4.x) is the automatic building and compiling of an MVC application using Sencha Cmd. This didn't exist yet for ExtJs 3.0. I think it is crucial that you start straight away using this tool. I will allow you to really take advantage of all the enhancements (declarative programming instead of imperative, advanced MVC and MVVM features). It will radically change your coding style.
To get this work, you compile in a first step you old code in one Javascript file. Sencha Cmd must not recognize this as an Ext app. Then you simply add requires: 'Oldapp' in Application.js and ExtJs will include a file called Oldapp.js. That file should define a class Oldapp and include all the rest of your application code:
Ext.define('Oldapp', {
// Just what ever you need
})
// All the rest of the code of you old app
Then layout all the folders and files of your new code according to the MVC or MVVM specification (whatever you prefer) in the Ext doc, and Sencha Cmd will build you the whole app correctly.
I think this all allows you to take advantage of all the new features immediately, building on a clean, standard foundation with only minor code refactoring. It sounds like eat the cake and have it too, but it is possible.
But this will take a huge mental step: You must learn ExtJs 5.0 like something new and try to forget all you know already about ExtJs. You won't use Ext.ready anymore, Ext.Loader will handle this under the hood. Nor will you instantiate Ext objects from declarations (ban panel = Ext.create({xtype: 'panel', ... stuff), stick to Ext.define('Myapp.view.Mypanel' .... There are many other points where everything changed since Ext 3.0 ...
This last point is in my opinion the biggest stumbling block, much more important than the two technical points explained before: It is difficult, but crucial to reeducate yourself.
You can use sandbox version of Ext Js 5.0 and "normal" 3.0 (I don't remember if 3.0 is also available as sandbox).
Then you can change prefix for all 5.0 classes and css rules. By default it is Ext4 (not Ext5) for JS, and x4- for CSS.
To use sandbox include ext-all-sandbox.js file from build directory.
It won't work. The javascript files will clash with each other.
We have started a new Asp .net web project. We plan to do in in MVC. Is it a good practice to use Microsoft's MVC 3 tool or is it good to define our own structure? Web site requirements are normal. Some people suggest if we use microsoft tool we will loose our control in the project????? Any problems that we may face when we use micosoft MVC 3 tool (Razor)?
no really, there isn't any problem -present and future; if you have deep knowledge about issues such as OOP, ASP.NET structure and how it works, MVC architecture, etc. I suggest you strongly use and enjoy ASP.NET MVC 3 and Razor :D
If you are new to MVC then I would suggest go through basic (or advance dependending upon how much you know) MVC tutorials before deciding arch. Things can be done in various ways and it differs from project to project. Once you build your knowledge about things like DomainModel, serviceLocator, IoC, ViewModel, Helpers, repository pattern etc. you will have better idea about which tool to use. I would start looking at some of the sample projects on the codeplex. (would not be too hard to find)
Good luck
If I said yes, would you go ahead and use it? The same goes for building a house or working on any project. What has worked for me, might not work for you. I would start from reading learning resources on here. I would also suggest reading about HTTP protocol and its stateless nature as well as looking at differences between web forms and mvc frameworks. Good luck.
I am starting a project with Sitecore, I have looked for different possibilities. I have some experience with MVC but I don't understand why you want to combine this with Sitecore (6.4).
What are the benefits? Are there any examples of the implementation of (the code of) this (not the configuration on: http://sdn.sitecore.net/upload/sitecore6/64/integrating%20an%20asp.net%20mvc%20web%20application%20in%20sitecore%20cms-usletter.pdf)?
Or why shouldn't I use MVC with Sitecore?
So when should I use Sitecore 6.4 with MVC3 and when not? And are there any (code)examples?
Thanks in advance!
I've successfully implemented my own MVP implementation using Sitecore. MVP is a bit more forgiving than MVC, and can easily be integrated into web forms based applications. I used T4 templates to generate Models directly from Sitecore templates using the built-in webservices which worked really well.
Sitecore doesn't support MVC yet (in the recommended release), and trying to make it work is probably not worth the effort. I believe they are working on a version that supports MVC properly, which may be the link you provided. However it's probably also very new and there is a lot of functionality in the old version that relies on web forms. I'd like to see it working under MVC in an official capacity for a few more iterations.
Implementing patterns such as MVC and MVP are all about separating concerns and making your presentation layer unit testable. It also encourages more elegant design.
Just reading the doc it looks like this is a guide for running Sitecore in parallel with MVC. I can't see anything about new rendering mechanisms for Sitecore, which would make templating difficult in anything other than web forms. It would however allow you to use the Sitecore API to build your own templates via MVC Views, but you would loose the inline editing functionality that you get out-of-the-box with web forms.
Using mvp is probably the simplest way to go. I wrote a blog post about it here.
However, we have used MVC3 with Razor before and it worked very well. The only issue is you lose the ability to use Page edit mode as you have to do some hacking of sitecore to get it to work. I'm contemplating writing a blog post about it if people are interested.
Just to follow up.. MVC is now supported in 6.6, which will be released on November 5th 2012. We just saw a demo from John West at the Sitecore Symposium and it looks like a great framework. One of the best things about it is that you can use MVC side-by-side with Web Forms. You don't have to make an all-in bet for MVC, you can just slowly migrate or build new components in MVC, while still running Web Forms throughout your site.
I currently have an ASP.NET MVC project with several other projects, class libraries mostly. I want to create a "mobile-friendly" version of the ASP.NET MVC app that uses the WURFL library, and I just want to know if it would be a bad practice to create a separate MVC solution? Or should I have the mobile detection within the same MVC project and serve up appropriate views? I just want to keep my concerns separate from an architectural point of view. Is it bad practice to do a redirection based on device?
I think it's better to create the separate solution cause:
1. You will know for sure that users use mobile devise for see this vertion
2. Sometimes autodetection not work correctly
3. Build the new solution can be faster that setup the mobile detection on old solution
PS> Sorry for my english :)