How we work
=========================================================

The screen-level contract
-------------------------

The example widgets is implemented as a **SlotStatefulWidget**.

At the very top of the widget,
its slot dependencies are declared explicitly.

This declaration defines the full set of application state
that the screen is allowed to read, and the state that can
trigger rebuilds.

As a result, the screen’s relationship to state is visible
and reviewable in one place.

This means that architects or team leads can prepare a
screen-level template in advance.

They can copy and paste this code, make small adjustments,
and hand it over to implementers with a clear contract.


.. code-block:: dart

    /// Slot definition file. e.g. app_state.dart
    import 'package:simple_app_state/simple_app_state.dart';

    // state and slots
    final appState = SimpleAppState();
    final countSlot = appState.slot<int>('count', initial: 0);
    final logsSlot = appState.slot<List<String>>('logs', initial: [], caster: (raw) => (raw as List).cast<String>());

.. code-block:: dart

    /// Class template file.
    import 'package:flutter/foundation.dart';
    import 'package:flutter/material.dart';
    import 'package:simple_app_state/simple_app_state.dart';

    class CounterPage extends SlotStatefulWidget {
      @override
      List<StateSlot> get slots => [countSlot, logsSlot];

      @override
      SlotState<CounterPage> createState() => _CounterPageState();
    }

    class _CounterPageState extends SlotState<CounterPage> {
      @override
      Widget build(BuildContext context) {
        final count = countSlot.get();
        final logs = logsSlot.get();
        return CreatedNewWidget();
      }
    }

----

Implementation inside the boundary
----------------------------------

Inside the state class,
the UI implementation is free to read and update
any of the declared slots.

The developer does not need to think about
subscription management or rebuild wiring.

All of that is handled by the slot boundary
declared at the widget level.

From the implementer’s point of view,
they are simply writing a normal Flutter **build()** method
with access to a clearly defined set of state.

By enforcing clear slot boundaries at the screen level,
project structure becomes easier to understand for both
humans and AI tools.

This clarity reduces integration friction between screens
and helps keep long-term maintenance costs under control.