Make a quotation explain itself.

Make the consequence of a choice visible.

A customer chooses a quantity or a service level and wants to understand the resulting estimate. Binding keeps the editor and summary connected. Formulas express local dependencies, so a preview can respond without a request for every small edit.

The benefit is explanation: people can see the inputs that produced the number. This is useful for internal estimators as well as customer-facing configuration.

Use different mechanisms for different changes.

Use a formula when quantity changes a subtotal. Use a controller when a command should run. Use dataRpc when a trusted price or availability must come from the host. Use remote when a selected product needs a different section of interface.

These pieces can share the same Data paths without creating separate client state for each concern. A summary remains a view of the current values.

An estimate is not a confirmed offer.

Local calculations may be stale or modifiable. A business service should validate the requested items and apply its own pricing, permissions and acceptance rules. An aborted or superseded browser request is not proof that a business operation was undone.

A real quotation also needs exact numeric types, an explicit rounding policy and a decision about what is included. The gallery multiplication lesson illustrates reactivity; it does not establish accounting correctness.

Build the smallest credible demonstration.

Begin with a quantity, a unit price and a reactive result. Add one service call with an observable error state. Then introduce a product-dependent Source fragment if the structure really needs to vary.

This scenario does not claim a bundled quotation database, order workflow or invoicing module. The value is a consistent set of primitives for the interface and its interactions.

KEEP EXPLORING

Follow the idea.