I've used NGRX for a few projects now and generally really like it. But I'm struggling with whether or not to use it in my next project which will be to create an angular component library.
Is it recommended to use ngrx in angular library project types? How would you setup the root state vs the feature state? Would my library project's main module attach to the ngrx root store? If so then if my library is used in a parent app that is also using ngrx would the root store's collide?
Update (More Context):
The majority of the components in the library will be typical forms of data type of stuff. For example providing components to search, update, create and delete things across multiple applications. We're packaging them up as a component library (and angular elements library) because they will need to be used in multiple web applications until those web applications converge into one new super web application (time line for convergence is 1+ year down the road). The other integration path we were looking at was loading an iframe in all these client apps.
The components themselves will connect to an API layer to do all the data I/O. Components may need to share parts of state across components.
This is hard to answer without having the full context.
If we're speaking about a "pure" component library, I would rather not pull in any state management libraries. If the component needs some state, it should manage its state on its own.
Components using this library can always be in control of the communication with the store.
Related
What libraries/techniques are available in Blazor for State management for webassembly (wasm).
It would be nice to know pros and cons of different approaches.
There are several options:
Redux (Fluxor)
Redux/Flux pattern has become a leader in state management in JS word; so it would make sense to adopt this best practice.
Luckily there is already a Fluxor library that does just that; and it does have the most github stars 379; although it is still a relatively new area; so it remains to be seen what ends up being the most adopted approach later on.
There is a great intro video along with source code
Official docs:
State, actions, and reducers
Effects
Redux Dev Tools
An in depth article.
Blazor-State
Blazor-State
Pros: uses MediatR for messaging
See also
Overviews of State Management Approaches
https://chrissainty.com/mobile-blazor-bindings-state-management-and-data/
https://jonhilton.net/blazor-state-management/
https://learn.microsoft.com/en-us/aspnet/core/blazor/state-management
nice but mostly messaging: https://jasonwatmore.com/post/2020/07/30/aspnet-core-blazor-webassembly-communication-between-components
keywords: passing data between blazor wasm webassembly components child parent attributes events handling
A Blazor app is a C# app on top of the .Net BCL libraries. We don’t need to emulate what the JavaScript world has created to overcome its own deficiencies. C# can cache anything you want with static members.
Please excuse my ignorance. I am coming from a non .net background and attempting to get up to speed but I have been having trouble finding good documentation on integrating react with ASP.NET Core MVC.
I am looking to utilize react.Net in order to implement server side rendering of react components...
The site for react.net has some example code on GitHub,
https://github.com/reactjs/React.NET/tree/master/tutorial-code
but the tutorial falls short of explaining how to utilize web pack. This solution is fairly useless to me as I need to be able to initially render react components for both speed and for being able to use data passed by the controller to the view without using a third party library to fetch data.
I was wondering if anyone had good insights or examples of how to utilize react.net in a way that allows for
1. reuse of react components using imports
2. allows passing data from the controller to the view to the component as a prop.
Thanks.
Hi I am new new to flex development.
I am building a flex application which uses rest APIs.
Right now I have created different for different API calls (login, logout, search etc.) And all these services are in main mxml application file.
I am wondering if I can create a separate mxml file like services.mxml that I can use to call any service.
Is this the right approach?
And can you tell me how t do this?
Thanks
Priyank
Yes, you can encapsulate Flex code so it is not all in the same file. Yes, you can also do this with services. In fact the Cairngorm framework uses that exact approach. [And I assume other frameworks do too].
When you create a component architecture the trick is figuring out how components communicate with each other. In Flex, a component can dispatch events to communicate with it's parent. And it can have methods or properties so the parent can communicate with the child.
Encapsulating all services to a single is fine, but you'll need to figure out components will access those services and how those services will send results back to the components. It's not a simple proposition.
I think you need to research the flex component lifecycle a bit and read up on creating Flex Components or ActionScript classes.
Here are a few resources:
http://www.adobe.com/devnet/flex/components.html
http://www.adobe.com/devnet/flex/articles/creating_components.html
http://livedocs.adobe.com/flex/3/html/help.html?content=Part4_CreateComps_1.html
I have a large flex application (the app) running on one server, and many small flex applications (widgets) running on another server, which are to be included in the app so that visually the user see's one continuous application. Due to proprietary third party software, this structure cannot be changed. I am looking for some way to allow the app and the widgets to communicate, allowing the app to make changes to the widgets and the the widgets to notify the app when events are triggered, so that user interaction is fluid and continuous.
There are a few related questions which indicate it's possible to do this by setting up event triggers and listeners. I am wondering if there is any standardized way to do this (the answers aren't very clear) or if anyone has developed a library or API to make this easier.
Something I've had success with is using javascript as a bridge between the swf files. It's a nightmare to debug but it works quite well. Check out the tutorial here for a quick discussion of how to interact with javascript from within flash and vice versa
I assume you are running your Flex apps on a client, not a server; is that correct? You want to swfs from multiple servers to act as single application, correct?
I believe that you can communicate between two swfs using LocalConnection:
http://www.adobe.com/livedocs/flash/9.0/ActionScriptLangRefV3/flash/net/LocalConnection.html
The other questions you link to seem to talk about loading onw swf inside the oher; which is a separate approach.
Use Modules and ModuleLoaders. You'll be able to set the security context, and if you sublcass the Module class and add your own API, you can have a consistent way to communicate with your modules.
Check here for a simple Module:
http://blog.flexexamples.com/2007/08/06/building-a-simple-flex-module/
I am planning on a Flex project that involves incorporation of a lot of features.
Each 'feature' can be a component / module.
Which is preferred and what is the difference between a module and a component?
Thanks
The short answer is that it depends.
If you going to use all, or most, of your components during regular execution of the application - components would be alright.
By the sounds of things though, modules might be the better bet for your project.
Modules allow you to group components into external libraries (RSLs). These libraries can be embedded into your application (through project settings) or can be loaded dynamically at runtime (as separate files).
Modules would give you some benefits
Only loading the libraries needed (as needed) instead of all modules everytime.
Load only core modules initially to speed up the initial load time.
Changes to a component do not require you to recompile the application/
Find out more about creating modules here.