If you have a question, please make a discussion post and I may post the outcome here!
Yes! As a general rule of thumb,
any side effect that mutates some state external to the build
and then returns that state or a value dependent upon that state
will likely trigger rebuilds.
As an example, setState updates a value extenal to the capsule build itself (it is a callback),
and use.state returns state, so it triggers a rebuild.
While use.memo updates a state value, it is done within the build itself,
so it doesn't trigger any rebuilds.
For capsules: yes.
Calling rebuild() multiple times in a row will trigger multiple rebuilds.
This is also true for calling different setStates or similar back-to-back;
multiple rebuilds are triggered.
As this is often undesirable, ReArch has "side effect transactions"
that can run a bunch of side effects in one batch to result in one rebuild.
final runTransaction = use.transactionRunner();
void updateMultipleEffectsInOneBuild() {
runTransaction(() {
setState1(1234);
setState2(4321);
invalidateFuture();
somethingElseThatMayRebuild();
});
}For Flutter widgets: no.
Rebuilds are automatically batched together on the next frame via flutter’s build scheduler
(ReArch internally calls
Element.markNeedsBuild).
You can read more about "side effect transactions" here.
use.register(), as it is often seen, is meant to implement rather low-level side effects,
and thus you often won't need to use it directly.
It essentially is a combination of a way to access the outside world
(via the SideEffectApi),
coupled with a way to call some certain function only on the first build,
which can be used to persist state across builds.
See https://github.com/GregoryConrad/rearch-dart/issues/79#issuecomment-1889770035 and https://github.com/GregoryConrad/rearch-dart/issues/79#issuecomment-1890421419.
