You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looking at the example in flutter_built_redux we see this:
class ConnectionExample extends StatelessWidget {
final Store<Counter, CounterBuilder, CounterActions> store;
I have a problem with this in that it is exposing internal details of the Counter class in the UI. The UI should not know anything about the existence of CounterBuilder. I don't even like having the UI know about the concrete Counter class and would declare an abstract class defining the interface the UI cares about (since there may internal parts of the state that is not exposed to the UI). So for the example let's say we declare this class that Counter implements:
abstract class CounterApi {
int get count;
}
The UI should only depend on this interface. With the normal version of redux you can easily refer to a Store<Counter> as a Store<CounterApi>, but we cannot do the equivalent with built_redux because the Store type has 3 type parameters now. The actions parameter is fine, but the Builder parameter is problematic.
So what is the solution? I understand that the Builder type is vital on actually creating the store but it is not necessary for users of the store, they only need state and actions. So the most likely solution is for you to refactor a super interface for Store:
abstract class StoreApi<State, Actions extends ReduxActions> {
/// [state] returns the current state
State get state;
/// [actions] returns the synced actions
Actions get action;
/// [nextState] is a stream which has a payload of the next state value
Stream<State> get nextState => stream
}
This will let you refer to the store using a variable of type StoreApi<CounterApi, CounterActions>
The text was updated successfully, but these errors were encountered:
Thinking about it some more, the only part of this whole system that should care whether state is a built value is the reducer. I am starting to question why this package exists as a competitor to the normal redux package when its core functionality, reducers that tailor to built values could actually just be implemented as an add on to the normal redux package. The other advantages I see here of possibly better middleware specification and a different way to specify actions could probably also be add-ons to instead of replacements of the redux package.
Looking at the example in flutter_built_redux we see this:
I have a problem with this in that it is exposing internal details of the Counter class in the UI. The UI should not know anything about the existence of CounterBuilder. I don't even like having the UI know about the concrete Counter class and would declare an abstract class defining the interface the UI cares about (since there may internal parts of the state that is not exposed to the UI). So for the example let's say we declare this class that Counter implements:
The UI should only depend on this interface. With the normal version of redux you can easily refer to a
Store<Counter>
as aStore<CounterApi>
, but we cannot do the equivalent with built_redux because the Store type has 3 type parameters now. The actions parameter is fine, but the Builder parameter is problematic.So what is the solution? I understand that the Builder type is vital on actually creating the store but it is not necessary for users of the store, they only need state and actions. So the most likely solution is for you to refactor a super interface for Store:
This will let you refer to the store using a variable of type
StoreApi<CounterApi, CounterActions>
The text was updated successfully, but these errors were encountered: