In a state machine I have a state which has an entry activity and that activity has an out parameter which contains the information about the next state.
This info is then checked in the transition conditions.
One of the pitfalls is that you may overlook a transition. I wanted to create a default transition that runs into a logging activity and returns the state machine into a stable condition without getting stuck in that state because no transition condition evaluates to true.
However I can't just have a conditionless transition because there appears to be no way to order the checks like one would do in a code switch statement.
Any advice would be appreciated.
Could you set your Out parameter to a default state e.g. "NoTransition", at the start of your activity. Then if the Out parameter is not set to a valid transition during the activity the "NoTransition" state is output and acts as the default and can be picked up by the transition conditions
Related
I need to make sure that children added to a DatabaseReference are processed in order. It is possible that the branch where the children are being added, gets multiple children added to it once. When the children are added at small intervals, everything works fine.
To tackle this, I've already implemented an index based solution. I add a field "index" in each child and ensure on Cloud Functions (the code that adds these children) that this index is incremental for all children. I then do the following to implement it:
MyDatabaseReference.OrderByChild("index").ChildAdded += HandleTheChild;
Most of the time this works, but there are still times when I get bugs similar to when I faced bugs due to wrong ordering of the children. My hypothesis is that the HandleTheChild function is triggered in order always, but it is possible that a child starts to be handled before the previous child is completely processed by the HandleTheChild function. This is creating some race conditions in their parallel execution. I want that each child be processed only after all previous children have been processed in the order they are arriving. Is my hypothesis wrong? If not, should I go forward with an implementation of the solution of the Producer-consumer problem on my Unity client?
When you first attach a listener to ChildAdded it fires for all children, in the order that you request them.
After that, the ChildAdded listener fires when a child is added to the database. In this case, the child may be inserted somewhere in the middle of the data (e.g. if its index is lower than existing indexes. The ChildAdded listener will fire and has a PreviousChildName property for this case. This contains the key/id/name of the number after which the new child was added.
My guess is that you're not using PreviousChildName, but (as Doug commented) it's hard to be certain without seeing that code.
In Redux once we dispatch an action we get a new state with the updated values . What happens to the previous old state ?
The old state is discarded. If you want to save it, you need to incorporate it as part of your state. One way to do that is explained here: Implementing Undo History.
Another option is to use an "Event Sourcing" model. Where your primary state is merely an array of all actions that have transpired and you have a derivative state that reduces the array in the primary state into a "current app state." Here's an explanation of the idea for Elm: Elm and Event Sourcing
Redux state is nothing but a javascript object in your memory. There is only one version of the state, which is your latest one.
When you dispatch an action, the action handler (reducer) is a pure function which will convert your old state to new state. state should be immutable, which means the action handler does not change the old state, but get the copy of it, and then change it depends on your action type, then return it. It will looks like ("--->" means dispatch):
initial state ---> state 1 ---> state 2 ---> state 3 ....
You can install the redux plugin in chrome, and you will see the whole history of the state.
So basically, redux does not save any old state, if you wanna trace the history, you have to do it yourself by using Stack or using some other libs.
I actually implement the event tracing using data structure stack, when state changes, you push to stack, when you wanna go back to previous state, you just pop the state and dispatch a special action to change the state, this special dispatch should not trigger push, very rough idea though.
Let's imagine I want to be able to select a task in the Todo with React-Redux.
Where should I store this state ?
First solution: Add a isActive: true attribut to the task
Second solution: Create a new reducer just to handle the id of the selected item.
I dislike both solutions: the first one feels like I'm storing something unrelated to the task in it, the second one feels overkilled to create a whole reducer only to store an id.
Is there any other option ? What's best ?
Thanks
I'd say it depends on your use case.
For a big app that has tons of UI state to persist, it makes a lot of sense to have a special reducer to mutate a slice of the store related to the UI.
It is valid to have a isActive: boolean property per task if you can have multiple tasks active at the same time. Even though it's not related to the task from the task data perspective, it actually is from an application perspective of the task. Your redux store main goal is to be your application source of truth rather than just mirroring your API data models.
You can also have a single isActive: id if you can only have a single task active/selected at the time.
You can also just use the component state. The limitation of this is that it won't persist and it won't be shared. For instance, if you want to have a save button, that button will have to be within the component that has the selected state.
There's nothing really wrong with either of the two options you've listed. But, if you're looking for other options, you can
1) Include the selected item in the todos reducer state, so your state object would look like this:
{
selected: id,
list: [{id, text, completed}, ...]
}
2) If you don't need the selected item anywhere else in your app, you can simply store it in your local state. There's nothing wrong with mixing both Redux for application state and local state for data contained solely within your component.
I have my reducer with a starting state of an empty array:
folderReducer(state:Array<Folder> = [], action: Action)
I'd like to populate the starting state, so when I do
store.subscribe(s => ..)
The first item I get comes from the database. I assume the way of doing this is with ngrx/effects, but I'm not sure how.
Your store always has the initial state, that you define in the reducer-function. The initial states main purpose is to ensure that the application is able to start up and not run into any null-pointer-exceptions. And also it sets up your application to start making the first api-calls ect. - so you can think of it as a technical initial state.
If you want to fill your store with api-data on the startup, you would do that on the same way that you add/modify data during any other action - just that the action of "initially loading data" is not triggered by some user-interaction but through:
either when your root-component loads
or as part of a service in the constructor
In case you want to prevent specific components from showing anything until your API-call is done, you would have to adjust the display-components to display or hide data based on your state (e.g. by implementing a flag in your satet initialDataLoaded).
A dynamic initial state is now supported, see: https://github.com/ngrx/platform/blob/master/docs/store/api.md#initial-state-and-ahead-of-time-aot-compilation
Also see: https://github.com/ngrx/platform/issues/51
I would only do this if the database is local, otherwise the request will hold up loading of the application.
In my main window (QMainWindow) I have a QTableView (named commandsTableView). Now I want to react on its selection changes.
I made a slot and connected it manually to ui.commandsTableView->selectionModel(). All works fine.
But then I thought: why not use auto-connection (especially that there will be more connections to be done)? At least it will add more force to consistent naming rules.
Yet I wasn't able to find proper name syntax. I tried:
on_commandsTableView_selectionModel_selectionChanged,
on_commandsTableViewSelectionModel_selectionChanged,
on_commandsTableView_selectionChanged,
on_commandsTableView___selectionChanged
but neither worked. In all cases there is there is a message on output when running the app (with corresponding slot name, here only first given as an example):
QMetaObject::connectSlotsByName: No matching signal for on_commandsTableView_selectionModel_selectionChanged(QItemSelection,QItemSelection)
(Why there are no assertions in response for connection errors - that I cannot understand. I lost much time wondering what is wrong before I spotted those - and alike - messages on output.)
The object returned by ui.commandsTableView->selectionModel() has an empty name. But setting it to selectionModel prior to making a call to connectSlotsByName doesn't help either.
According to the documentation connectSlotsByName() only supports signatures like
void on_<object name>_<signal name>(<signal parameters>);
According to the sources that's the only form it checks (watch how it collects a list of children, then matches parent's method names against names of the children).
Hence, to be able to use auto-connection you would have needed a named selection model, which would continue existing from the call to connectSlotsByName() onwards. Each time you change the selection model (not likely) or the model (likely) you'd have to name the selection model and auto-connect again. But alas connectSlotsByName() will duplicate all other connections as it doesn't seem to check if connections are unique, so we have to connect signals to such dynamic children as models, scenes etc manually.
I think it's
on_selectionModel_selectionChanged(const QItemSelection & selected, const QItemSelection & deselected)