Frequently Asked Questions

If you have a question, please make a discussion post and I may post the outcome here!

Do state side effects trigger rebuilds internally?

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.

Does rebuild() trigger rebuilds immediately? Or can you call it back-to-back?

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.

(Dart/Flutter) What is the purpose of SideEffectRegistrar.register()?

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.