Update state of two independent components in react-native.
For example I have two components like contributorOne and contributorTwo, based on some event happening in contributorOne I want to update the state of contributorTwo data.
There is no parent child relationship in contributorOne and contributorTwo components, so can anyone help me with this.
You might want to explore an option such as Redux or another form of a flux architecture, which keeps a global state instead of using a per-component state. That way, when an action occurs in one component, it can dispatch an update to the global state which the other component can be subscribed to. There is no necessity for a shared parent relationship in this architecture, either, which seems to fit your requirements.
Related
Background
Say I have 30 sqlite db entities with their corresponding individual dart class models. Of those, many are aggregated and shown in several widgets of the app. CRUD operations should re-run the corresponding aggregation and update the respective ui/widgets that consume the data.
Current state
Today I read from the db every time I build the widgets.
Need
How can I have generic provider/listener for the aggregations as well as the entities without creating one provider for each entity and aggregated view? It should be able to resolve which widgets to update.
I want to have a state management layer, with a dependency tree, as opposed to reading from the db every time the widget is built.
The way I understand it is that you want to have state management with the provider package, but you don't want to create types that extend ChangeNotifier to manage your data models.
You gonna have to extend ChnageNotifier in order to call notifyListeners where needed to update your UI. So at least create one type that extends ChangeNotifier, and have it manage all of your data objects. Generally, this is not a good as there is no reason not to create a type per each model.
I've been reading a lot about Entity Frameworks and now I want to implement it on my game. An Entity Framework is based on making the game entities simple containers of Components, where a Component contains a certain characteristic of an Entity (and all the variables/accessors which describe this characteristic).
The game logic is then modularized by creating Systems. Each System implements and runs a certain aspect of the game logic (eg. Collisions, Rendering, Animation). Each System has to be able to access every Entity which has some certain combination of Components (eg. RenderSystem has to get only Entities which have PositionComponent and AnimationComponent).
My question regards the best data structure for achieving such functionality.
My current idea is to create a Vector (with N cells, where N is the number of possible components) of List of Entity. So whenever I create (instantiate and add certain Components) an Entity, I would also reference this Entity from each List for each Component it contains. "Killing" an Entity would require removing each reference from each List. The problem would be querying which entities have to be processed by a certain System, because the search-key would be a combination of Components, and not a single Component, adding overhead to the operation (many searches and comparisons would have to be done).
Is my idea good? Is there any better data structure I can use? Note that everything in the game is supposed to be an Entity, summing up to thousands of Entites on a single Level (I could possibly use some space partitioning).
They are two ways of doing it,
The purely data oriented system would lead you not to have an Entity class but just components sharing an ID. In this case, a vector or a hashmap for every system wouldn't be a problem as the search in these data structure is fast. If you want several components per system per entity you can aggregate your components in one data structure adapted for each system.
The problem is that a pure data oriented system can be less usable than a more pragmatic approach where you keep all the features of the previously described system but you keep an entity class that holds reference to his components (or aggregated components structures) of every system. Processing an entity (deleting or inspecting it) becomes much easier as you still have a place where all the information about what the entity is, i.e. what it is made of and not what state it is in, can be found in one place instead of querying every system.
In your case, the best thing is to try... It's quite easy and fast to implement a rough engine in the two ways, and once you've played with the two you'll be able to decide which one suites you better.
This article is valuable as far as it suggests 4 iterations for the data structure, but no one is a good solution in my opinion. But I recommend to read it, because there is a detailed analysis of the problem, nice estimations in terms of memory and such other good material.
I have some questions regarding the entity framework context instance management.
My code base is composed of many independent components/agents all running in one process that can only do work by reading messages from their corresponding queues at their convenience(whenever the component is ready, it will pick up the next message from the queue so no concurrency issue at the component level)
Each of the components need to interact with the database independent from other components. I am wondering what is the better way to setup the context instance/s for each component. Here are some of the options
1> Have one instance of the the context used by all components. --> I think this is the worst as it creates many concurrency issues?
2> Give every component an independent instance of the context. --> This looks fine but
is it ok to have many context independent instances in one process while all components are running concurrently in this process?
should I create a new instance of context for every new message that the component will process or keep one context instance for the life of the component? I think the last one makes more sense but I am more used to use context in a using{} bracket and I am not sure if keeping one context live for the life of each component has any complications in the way I am using it?
can I rely on optimistic concrruency so that two different independent components won't put same record in the database given all contexts are in one process?
BTW, I am using entity framework 4.1.
Definitely use one context per component / agent - if component is multithreaded use one context per thread. If each message processing is executed as separate "logical transaction" then use one context per message processing.
Why:
Context internally uses two very important design patterns - Identity map and Unit of work. This answer describes the behaviour enforced by these patterns.
Context and anything else in EF is not thread safe.
Optimistic concurrency doesn't mean that different contexts will not put the same record in the database. Optimistic concurrency means that update statements compare current state in the database with last known state by the context (there is a delay between loading record and saving new values and another context can change the record). If record changed you will get an exception and you must handle it somehow.
I'm still learning about Unit of Work patterns, repository patterns, etc.
My app:
I have a list of entities, say customers in a listview
When I select a customer a detail form shows, where their details can be edited
I'm trying to understand the standard MVVM/Entity Framework way of accomplishing the following:
When the user edits a customer it shows as "changed" (but not saved)
The user can chose to either save the current customer, or save all the changed customers
The Save or Save All commands/buttons are disabled if that option is not available (the current customer is unchanged, or all customers are unchanged)
Seems simple enough? But I have no idea how to approach this using MVVM/EF. Do I use UoW, do I detach objects and re-attach to the context so I can save them one at a time? How do I detect if an object is changed or unchanged?
Help! Thanks!
I throw in a few remarks:
The critical point in your requirements is in my opinion the option to save either one single customer or all changed customers. You need to take into account that Entity Framework doesn't have a method to save changes of a single or a few selected objects in the context. You can only save the changes of the whole Unit of Work (which is the ObjectContext or DbContext in EF) by calling myContext.SaveChanges().
This leads to the conclusion that you cannot use the list of all customers and the customer detail form in one single Unit of Work (= EF context) which holds all customers as attached entities. If you would do this you could provide a function/button to save all changes but not an option to save only the current customer in the form.
So, I would either think about if you really need those functions or I would work with the entities in a detached state. This would mean that you have to load the customer list from the database and dispose the context after that. When you save the changes - and now it doesn't matter if all changes or only changes of a single customer - you can create a new context, pull the original entity/entities from the database and update with the changed properties.
But working with either attached or detached entities - or either having one living EF context per view/form or creating only one short-living context per CRUD operation - is an important design decision in my opinion. Generally the possibility to have your entities attached to a context during the lifetime of a view/form exists to make your life as programmer easier because it offers you features like lazy loading and change tracking out of the box. So you might think twice if you want to give this up.
To recognize if a customer object has been changed or not the EF context could be helpful because it tracks the state of an object. You could for instance query the ObjectStateManager for a customer and check if it is in a "Changed" state. But to have this option you would need to work with attached entities as explained above. Since you cannot save (or also cancel) single object changes it is questionable if it would make sense at all to show the user that customer 1 and customer 3 has changed. (I would probably only show "some customers have changed".)
If you are working with detached entities you have to manage by hand which customers have changed or not by implementing some kind of "dirty flag" logic. Here is a thread about this:
Different ways to implement 'dirty'-flag functionality
I have created a data model with in EF 4.0, however I am not sure how I can capture things like Triggers in this model so that if others were to deploy it the Tables, Views, Triggers, etc would go along with it. Is there a way to pull triggers into the model build?
Thanks!
--B
Putting event handlers on your entities is definitely not the same thing, but it might do the job depending on what you need. Some references I've used for this if you need them:
How to: Execute Business Logic During Scalar Property Changes
How to: Execute Business Logic When the Object State Changes
How to: Execute Business Logic When Saving Changes
Entity Framework (EF) – Events (this one's pretty good)
Not sure if you've already done what you wanted to do, but HTH.
Edit: One dumb mistake I made: Watch out for infinite loops if you use an OnPropertyChanged or OnPropertyChanging event to alter another property (in my case, it was MyEntity.DateModified).