Using react hooks inside xstate machine invoke (e.g. react-query's useQuery)

[xvrdm]

Has anybody managed to use a react hook inside the 'invoke' part of a machine?

I have a machine that uses fetch in the src of one of its invoke parts. It works well.

I am now trying to change this code to use useQuery from react-query. This yields an error that seems to indicate that hooks cannot be used in a machine (or any other non-react component).

React Hook "useQuery" is called in function "getMatPatients" that is neither a React function component nor a custom React Hook function. React component names must start with an uppercase letter  react-hooks/rules-of-hooks

The react code:

async function getMatchingPatients(matriculeSearch: any) {
  let url = `/api/patients/{matriculeSearch}`;
  const res = await fetch(url);
  const json = await res.json();
  return json;
}

export const PatientSearch = () => {
  const [state, send] = useMachine(matFinderMachine, {
    devTools: true,
    services: {
      getMatPatients: (context, _) =>
        useQuery(["getMatchingPatients", context.search], getMatchingPatients),
    },
  });

  ... <rest of the React component > ...

the machine code:

...
      loading: {
        invoke: {
          id: "getPatient",
          src: "getMatPatients",
          onDone: {
            target: "selecting",
            actions: assign({ patients: (context, event) => event.data }),
          },
          onError: {
            target: "typing",
            actions: assign({ error: (context, event) => event.data }),
          },
        },
      },
...

Thanks for the awesome work on xstate (and the FEM courses): first time I find state machines approachable!

[Andarist]

Nobody has managed to do it because it's impossible. For hooks to work you have to use them throughout the whole lifetime of your component, unconditionally.

From what I understand react-query exposes non-hooks APIs (hooks "only" wraps them) but I don't know how much of a chore it is to use those APIs.

[denisborovikov]

Ok I used the approach from above for almost a year and gathered some feedback.

When you work with RQ mutations and XState - everything is perfect. It works as expected, there's no additional code required to the existing hooks to make it work with XState.

But with queries, this is somewhat different. There are several caveats with using this code:

const App = () => {
  const { refetch } = useQuery(['users'], () => axios.get('/users'), { enabled: false })

  const [state, send] = useMachine(machine, {
    services: {
      async getUsers() {
        const response = await refetch({ throwOnError: true })
        return response.data
      }
    }
  })
}

1. We need not to forget adding additional arguments here and there (enabled and throwOnError)
2. There’s no way to modify the original request and pass different arguments
3. refetch method ignores the cache and makes a new request no matter what

Eventually, I came up with using ensureQueryData.

1. It requires writing additional code to the existing useQuery, but the changes are minimal.
2. It resolves all issues from above.

// Extract queryKey and queryFn so they can be shared
function getQueryArgs(filter) {
 const queryKey = 'user'
 const queryFn = () => getUser(filter)
 return { queryKey, queryFn }
}

function useGetUser({ filter }) {
  const {queryKey, queryFn} = getQueryArgs(filter)
  return useQuery({ queryKey, queryFn })
}

function getUserData({ filter }) {
  const {queryKey, queryFn} = getQueryArgs(filter)
  return queryClient.ensureQueryData({queryKey, queryFn})
}

And XState service

const [state, send] = useMachine(machine, {
  services: {
    async getUser(ctx) {
      const response = await getUserData({ filter: ctx.filter })
      return response.data
    },
  }
}

As you can see, you can modify the request and pass data from the machine context.

You might want to use fetchQuery instead of ensureQueryData if you want to pull fresh data from API instead of using possible stale data from the cache.

[derek-primumco]

Thanks for sharing @denisborovikov! 🙏 That's a great example.

How would you recommend actually getting the response's data into the machine's context?

The example given in the XState v4 docs doesn't use an assign action to update context, so I think I'm missing something.

I'd love to hear what you've found works well!

[denisborovikov]

hey @derek-primumco, you are on the right way. You need to use assign and event argument. Check this example from the docs.

{
  invoke: {
    src: 'myService',
    onDone: {
      target: 'nextTarget',
      actions: assign({ foobar: (context, event) => event.data })
    }
  }
}

[derek-primumco]

Thanks @denisborovikov, that's really helpful. I appreciate it!

[denisborovikov]

A follow-up to my previous message, since the question on how to use XState and React query (TanStack Query) is still valid for many devs.

We started using react-query-kit to create mutations/queries. When a query or mutation is created this way, additional methods are attached to the hook (getOptions/getFetchOptions are the ones we're looking for).

Here's the simplified example of using RQ, react-query-kit, and XState:

Hook

import { createQuery } from 'react-query-kit'
const usePost = createQuery({
  queryKey: ['posts'],
  fetcher: (variables: Variables): Promise<Data> => {
    return fetch(`/posts/${variables.id}`).then(res => res.json())
  },
})

Actor implementation:

const queryClient = useQueryClient()

const [state, send] = useMachine(machine.provide({
  actors: {
    getPost: fromPromise(async ({ input }) => {
      const data = await queryClient.ensureQueryData(
        usePost.getOptions(), // getOptions is provided by react-query-kit
      )

      return data
    }),
  },
}))

Having getOptions/getFetchOptions gives us an easy way to use a full range of QueryClient methods.

With RQK, you can use hooks in your app as before, where you don't need XState. The same code can be re-used to request data as an XState promise actor.

[peraltafederico]

Hey @xvrdm

I created this codesandox as an illustration of how to use xstage + react-query. I think it might help: https://codesandbox.io/s/xstate-react-query-emeyl

Any suggestion is welcome!

[TkDodo]

Hi, react-query maintainer here. I know little about xstate, so bear with me please 😅 .

While queryClient.fetchQuery works, this doesn't create a subscription for your components to the query cache. I also see this a bit as a mixture of server state (react-query) and client state (xstate). You can't, for example, use options that are only available on a per-observer level, like select, enabled and keepPreviousData.

Am I wrong in seeing xstate being a very good match for complex client state, where [state, send] from useMachine are conceptually similar (albeit much more powerful) to [state, dispatch] from useReducer, and having the result (state) of the machine drive the query, but react-query would still be in charge of "managing" it ...

If I want to trigger a fetch when a certain state is reached, why not use the enabled option on useQuery to trigger it? This could be abstracted together in a custom hook.

[davidkpiano]

Hey @TkDodo 👋

Am I wrong in seeing xstate being a very good match for complex client state, where [state, send] from useMachine are conceptually similar (albeit much more powerful) to [state, dispatch] from useReducer, and having the result (state) of the machine drive the query, but react-query would still be in charge of "managing" it ...

XState is conceptually a state orchestrator, so it's responsible for orchestrating both client- and server-side state, and more. However, that doesn't mean it has to be responsible for managing server-side state, but the way it manages it is ideally framework-agnostic (and, in this case, ideally separate from the notion of React components).

This is not ideal:

const [enabled, setEnabled] = useState(false);
const {data, /* ... */} = useQuery('...', { enabled });
const [state, send] = useMachine(someMachine);

useEffect(() => {
  if (state.matches('loading')) {
    setEnabled(true);
  } else {
    setEnabled(false);
  }
}, [state]);

useEffect(() => {
  data && send('DATA_READY', { data });
}, [data]);

Because now there are a few problems:

• The orchestrator (useMachine) now has no idea that a fetch is occurring; it's "orchestrated" completely separate from the machine
• Cancellation becomes more awkward now as well (XState automatically "ignores" cancelled invocations)
• enabled also feels awkward; the intention is to start fetching, so some start() method (imperative) makes more sense than triggering this implicitly via a boolean (enabled) and potentially causing an unnecessary rerender
• Two useEffect calls to orchestrate one invoke
• There's now three places where state needs to be managed (useState, useQuery, useMachine)

I might be missing something, but I'm going to explore the react-query API more to see how we can make this work, even with subscriptions (service-level, not component-level), if that API is exposed and available in non-component contexts.

[TkDodo]

This is not ideal:

I agree, it's not. The "problem" is that react-query is hooks based, so a lot of functionality, like subscriptions and partial subscriptions via selectors, pausing and starting queries (enabled), triggering smart refetches and keeping previous data on screen without a hard loading state (via changing the query key and keepPreviousData) are features of the QueryObserver, which is what the hook is creating.

Again, I'm missing some knowledge about xstate (need to read up on it too 😅 ), but I think we can get rid of at least on eeffect by getting rid of the enabled local state completely and drive the query via state.matches, something like:

const [state, send] = useMachine(someMachine);
const {data, /* ... */} = useQuery('...', { enabled: state.matches('loading') });

DATA_READY also assumes that we have to pass data from react-query to xstate, and I'd usually consider that state-syncing: the state now lives in two places, which seems suboptimal.

I'm not sure how we can marry the two. Maybe we'd need to create a QueryObserver somewhere in the useMachine lifecycle? Or am I overthinking this?

[gabro]

Hi, coming back to this to present what I've tried. Given a machine like:

todoListMachine

export const todoListMachine =
  createMachine(
    {
      context: { todos: [] as Todo[] },
      tsTypes: {} as import("./todoListMachine.typegen").Typegen0,
      schema: {
        services: {} as {
          readTodos: { data: Todo[] };
        },
      },
      initial: "loading",
      states: {
        loading: {
          invoke: {
            src: "readTodos",
            onDone: [
              {
                actions: "setTodos",
                target: "ready",
              },
            ],
            onError: [
              {
                target: "error",
              },
            ],
          },
        },
        ready: {
          on: {
            retry: {
              target: "loading",
            },
          },
        },
        error: {
          on: {
            retry: {
              target: "loading",
            },
          },
        },
      },
      id: "todoListMachine",
    },
    {
      actions: {
        setTodos: assign({
          todos: (_context, event) => event.data,
        }),
      },
    }
  );

I have tried to define the readTodos service in terms of react-query like:

function TodoList() {
  const queryClient = useQueryClient();

  const [state, send] = useMachine(todoListMachine, {
    services: {
      readTodos: () => {
        const observer = new QueryObserver(queryClient, { queryKey: "todos", queryFn: getTodos });
 		return observer.refetch().then((result) => {
        	if (result.isError) {
      			throw result.error;
    		}
    		return result.data!; // ! since we know the query is enabled so data can't be undefined
  		});
	  }
    }
  });

  // ...
}

(where getTodos returns a Promise<Todo[]>)

This works but I don't think refetch does everything useQuery does, specifically it seems not to take the optimistic results into consideration.

So I've tried something like:

readTodos: () => {
  const observer = new QueryObserver(queryClient, options);
  const result = observer.getOptimisticResult(options);
  if (result.isSuccess && !result.isStale) {
    return Promise.resolve(result.data);
  }
  return observer.refetch().then((result) => {
    if (result.isError) {
      throw result.error;
    }
    return result.data!;
  });
}

But again, that's a gross approximation of what useQuery does, and I don't think it's correct.

@TkDodo am I anywhere close something that makes sense on the react-query side?

(Note, I've also tried returning the query observer directly, but it's not compatible with the Observable interface required by xstate. I didn't explore it further, but that may also be another option)

[zacharyweidenbach]

@gabro
this approach is close to what I had in my head when thinking about how to use react-query's useQuery in a more imperative way, so I could invoke queries as regular promises in my machines. The main difference between what I was thinking and what you have was to call the queryClient.getQueryCache() to check if I should invoke the query promise, or return the data it already has
https://react-query.tanstack.com/reference/QueryClient#queryclientgetquerycache

But it has the same problem that your approach has overall, which is that it doesn't honor the configuration options for the query, such as the stale time, or keepPreviousData etc. That functionality would need to be reimplemented by this wrapper function, instead of letting react-query handle that. By the sound of it though, react-query is heavily opinionated with its architecture towards hooks.

There is another issue - if your readTodos gets invoked at the same time in two difference places in your code for some reason. If that happened, you could have a double fetch because neither invoked instances will know the other was invoked first and the promise is still pending. You might be able to check for that with an isLoading flag, but you'd still need to resolve the promise in that case when the first promise resolves. State machines happen to be a great way to handle this situation. If you have a singleton query machine that is currently performing the query, and is sent an event to query again while it is still in the process of querying, the second caller can just receive the same resolved state as the first caller when the query machine finishes. I built a rudimentary version of this here for a personal project:
https://github.com/zacharyweidenbach/react-native-test-sandbox/blob/main/NativeFSM/store/utils/queryMachine/index.ts

I like react-query for how it abstracts the complexity of api caching to simplify the interface with your network requests. But it's implementation is unfortunately very tightly coupled with the react way of doing things (hooks, etc.). "React" is in the name after all, so this isn't surprising. But it seems like there is room for someone to build something that is framework agnostic like xstate, with additional packages for bridging it into specific frameworks like react or svelte or vue etc. Or it can just be used "raw" directly with a subscription interface.

[gabro]

@zacharyweidenbach I agree, there seems to be a lot of orchestration happening in useQuery right now to meaningfully replicate it in a wrapper without losing some functionality.

That said, the fact that QueryObserver exists is already a good step in the right direction, hopefully react-query will add even more functionalities to the core package 🤞

[leepowelldev]

Did this get any further? It would be great to have a non-hook API from react-query that could be alongside xstate.

[ChrisShank]

Nothing tangible yet, but there is a part of react query that is framework agnostic now and I think David has started exploring what @xstate/query could look like!

[leepowelldev]

This is great news! Excited to see the end result.

[joernroeder]

Wow, love to see where this is going as well

[xvrdm]

Thanks anyway for sharing. It’s still a very interesting approach.

…

On Fri, Oct 14, 2022 at 23:44, Denis Borovikov ***@***.***> wrote: I've found this approach doesn't work if you need to pass query parameters from the machine's context/event to useQuery. refetch allows you to refetch the existing query but there's no way to modify it for now. — Reply to this email directly, [view it on GitHub](#1813 (reply in thread)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAXXBTN7KHH6AKWMNODSNBLWDHH2LANCNFSM4VU24IVQ). You are receiving this because you were mentioned.Message ID: ***@***.***>

[denisborovikov]

I see this approach (the first example with no refs) is less verbose compared to the code above. You completely ignore onError/onDone callbacks from the services and have to call onSuccess/onError manually.

const [state, send] = useMachine(machine, {
  services: {
    async createUser(context, event) {
      const response = await mutateAsync(event.data)
      return response.data
    }
  }
})

creating: {
  invoke: {
    src: 'createUser',
    onDone: {
      target: 'created',
      actions: assign({
        userId: (_, event) => event.data.id
      })
    },
    onError: { target: 'error' }
  },
}

[bmadone]

@denisborovikov thanks a lot, a made refactoring, and now it's much better, the number of states reduced

[trickydisco78]

So what is the best way to do this? It's how I do this.

Full code can be found here: https://github.com/bmarvinb/moggl/blob/main/src/features/timer/machines/TimerMachineProvider.tsx

And code of my machine: https://github.com/bmarvinb/moggl/blob/main/src/features/timer/machines/TimerMachine.ts

export function TimerMachineProvider(props: {
  timeEntryInProgress: O.Option<TimeEntryInProgressModel>;
  children: React.ReactNode;
}) {
  const { mutate: stopTimeEntry } = useStopTimeEntry();
  const { mutate: updateTimeEntry } = useUpdateTimeEntry();
  const { mutate: deleteTimeEntry } = useDeleteTimeEntry();
  const queryClient = useQueryClient();

  const service = useInterpret(timerMachine, {
    services: {
      stopTimeEntry: () => send => {
        stopTimeEntry(undefined, {
          onSuccess: async () => {
            await queryClient.invalidateQueries(['timeEntries']);
            send('SAVING.SUCCESS');
          },
          onError: () => send('SAVING.ERROR'),
        });
      },
      discard: context => send => {
        invariant(context.id, 'Id must be provided');
        deleteTimeEntry(context.id, {
          onSuccess: () => send('DISCARD.SUCCESS'),
          onError: () => send('DISCARD.ERROR'),
        });
      },
    },
    actions: {
      updateTimeEntry: context => {
        invariant(context.id, 'Id must be provided');
        updateTimeEntry(
          {
            id: context.id,
            data: {
              start: context.start,
              billable: context.timeEntry.billable,
              projectId: context.timeEntry.projectId || undefined,
              description: context.timeEntry.description,
            },
          },
          {
            onSuccess: () => console.log('Time entry updated'),
            onError: () => console.error('Time entry update failed'),
          },
        );
      },
    },
  });

  const [timerState, timerSend] = useActor(service);

hi @bmarvinb Any chance you could share your github src for that (getting a 404 now) ? Would love to see how you integrated it all. I really want to use useMutation within xstate and interested in the invalidate queries part

[gavinthomas-valtech]

I guess you'd need to throwOnError option to invalidate queries here?

await queryClient.invalidateQueries(['timeEntries']);

[bartstc]

I started adapting XState in the React application maybe 6 months ago in my company and in my POV, if you want to adapt the Actor Model in your app, it's worth considering the difference between state management and state orchestration. After that, it won't be that challenging to integrate XState with TanStack Query, React Router Dom, React Hook Form, Jotai, or whatever library/state manager you decide to use (if you need them OFC).

My solution is based on two core architectural assumptions which I explained at the bottom of this comment for people who are curious:

• Decoupling application logic from infrastructure and presentation logic
• Decoupling state management from state orchestration

So here is a type-safe solution for aligning XState v5 with TanStack Query v5 (it's not ideal but for now it's the best I can come up with):

// product-machine.ts

import type { ActionArgs, PromiseActorLogic } from 'xstate';
import { assign, setup } from 'xstate';

import type { Product } from '@/modules/products/models/product';
import type { UnionOf } from '@/shared/types/union-of';

export type ProductMachineContext =
  | {
      type: 'PRODUCT_SELECTED';
      productId: string;
    }
  | {
      type: 'PRODUCT_FETCHED';
      productId: string;
      productName: string;
    };

export type ProductSelectedMachineContext = UnionOf<
  ProductMachineContext,
  'PRODUCT_SELECTED'
>;
export type ProductFetchedMachineContext = UnionOf<
  ProductMachineContext,
  'PRODUCT_FETCHED'
>;

type ProductMachineEvent =
  | { type: 'PRODUCT_SELECTED'; productId: string }

type MachineActionArgs = ActionArgs<
  ProductMachineContext,
  ProductMachineEvent,
  ProductMachineEvent
>;

type ProvidedAction = (args: MachineActionArgs, params: undefined) => void;

type OnProductSelectedProvidedAction = (
  args: MachineActionArgs,
  params: string
) => void;

export type ProductMachineActions = {
  onProductSelected: OnProductSelectedProvidedAction;
  onProductUnselected: () => void;
};

export type ProductMachineActors = {
  getProduct: PromiseActorLogic<Product, string>;
};

// really simple machine example
export const productMachine = setup({
  types: {
    context: {} as ProductMachineContext,
    events: {} as ProductMachineEvent
  },
  actions: {
    ...({} as ProductMachineActions),
    setProductId: assign(({ context, event }) => {
      if (event.type !== 'PRODUCT_SELECTED') return {};

      return {
        ...context,
        type: 'PRODUCT_SELECTED',
        productId: event.productId
      };
    })
  },
  actors: {} as ProductMachineActors
}).createMachine({
  id: 'productMachine',
  intial: 'idle',
  on: {
    PRODUCT_SELECTED: '.productSelected',
  },
  states: {
    idle: {
      on: {
        PRODUCT_SELECTED: {
          target: 'productSelected',
          actions: [
            'setProductId',
            {
              type: 'onProductSelected',
              params: ({ event }) => event.productId
            }
          ]
        }
      }
    },
    productSelected: {
      exit: 'onProductUnselected',
      initial: 'fetching',
      states: {
        fetching: {
          invoke: {
            src: 'getProduct',
            input: ({ context }) =>
              (context as ProductSelectedMachineContext).productId,
            onDone: {
              target: 'fetched',
              actions: assign(({ context, event }) => ({
                ...context,
                type: 'PRODUCT_FETCHED',
                productName: event.output.productName
              }))
            },
            onError: {}
          }
        },
        fetched: {
          on: {
            PRODUCT_SELECTED: {
              target: 'productSelected',
              actions: [
                'setProductId',
                {
                  type: 'onProductSelected',
                  params: ({ event }) => event.productId
                }
              ]
            }
          }
        }
      }
    },
    error: {
      type: 'final'
    }
  }
});

// ProductMachineProvider.tsx

import { useActorRef, useSelector } from '@xstate/react';
import type { PropsWithChildren } from 'react';
import { createContext, useContext } from 'react';
import { fromPromise, type ActorRefFrom, type SnapshotFrom } from 'xstate';

import { useGetProduct } from '@/features/products/providers/api/use-product-query';

import type { ProductMachineActions, ProductMachineActors } from './product-machine';
import { featureDrawerMachine } from './product-machine';
import { useHandleProductIdParam } from './use-handle-product-id-param';

export const ProductMachineContext = createContext(
  {} as ActorRefFrom<typeof productMachine>
);

export const ProductMachineProvider = ({
  children
}: PropsWithChildren) => {
  // router (react-router-dom) logic
  const { appendParam, deleteParam } = useHandleProductIdParam();
  // fetching (tanstack-query) logic (prefetching the product so that it can be already fetched in the `useQuery` instance inside a component)
  const getProduct = useGetProduct();

  const actor = useActorRef(
    // provide everything what's external to application (router logic, fetching logic etc)
    productMachine.provide({
      actions: {
        onProductSelected: (_, productId) => appendParam(productId),
        onProductUnselected: deleteParam
      } satisfies ProductMachineActions,
      actors: {
        getProduct: fromPromise(({ input }) => getProduct(input))
      } satisfies ProductMachineActors
    })
  );

  return (
    <ProductMachineContext.Provider value={actor}>
      {children}
    </ProductMachineContext.Provider>
  );
};

export const useProductMachineSend = () => {
  const service = useContext(ProductMachineContext);
  return service.send;
};

export function useProductMachineSelector<T>(
  selector: (emitted: SnapshotFrom<typeof productMachine>) => T
) {
  const actor = useContext(ProductMachineContext);
  return useSelector(actor, selector);
}

// use-product-query.ts

import { useQuery, useQueryClient, queryOptions } from '@tanstack/react-query';

import { useCurrentTenantIdSelector } from '@/modules/auth/application/use-current-tenant-id-selector';
import { productsQueryKeys } from '@/features/products/providers/api/products-query-keys';
import { useHttpClient } from '@/shared/lib/api/use-http-client';

import type { Product } from '../../models/product';

const useGetQueryOptions = () => {
  const tenantId = useCurrentTenantIdSelector();
  const httpClient = useHttpClient();

  return (productId: string) =>
    queryOptions({
      queryKey: productsQueryKeys.detail(tenantId, productId),
      queryFn: async () => {
        const result = await httpClient.get<Product>(
          `v1.0/${tenantId}/products/${productId}`
        );

        if (result.type === 'ERROR') throw result.reason;

        return result.value;
      }
    });
};

export const useProductQuery = (productId: string) => {
  const getQueryOptions = useGetQueryOptions();

  return useQuery(getQueryOptions(productId));
};

export const useGetProduct = () => {
  const queryClient = useQueryClient();
  const getQueryOptions = useGetQueryOptions();

  return async (productId: string) =>
    queryClient.ensureQueryData(getQueryOptions(productId));
};

To be clear, I overcomplicated it a bit to show my point. And types could be probably more readable and reusable (didn't devote too much time to it :)). Lastly, in many cases, it won't (shouldn't?) be necessary to prefetch query as shown above through useGetProduct hook. It all depends on your needs, the application's structure, and the components' hierarchy.

Application, Infrastructure, Presentation

• Infrastructure - The layer responsible for networking and data fetching. This is where we define the queries to the api and the corresponding keys, the mapping of data structures, the hooks responsible for sending data and other logic involved in communication with external services (api, websocket, etc.). Dependencies to libraries such as tanstack-query, next/cache, or native fetch should not leak beyond this layer.

• Application - The layer responsible for the "state" of a particular module. The quotation marks in the word "state" mean that it is not only about the technical aspect (application state: useState, useReducer, useContext, etc.), but also, and above all, state management, state orchestration (FSMs and Statecharts), or e.g. form validations. It tracks business processes and provides components with the behaviour to emulate.

• Presentation - The presentation components with a local components' state and the UI markup are located here. You can think of it as a set of loosely connected components that build a specific part of an interface. Components prepared in this way, through composition, are used in the pages (Vite) or app (Next.js) directory to create a complete view presented to the user. Components are (should be) decoupled from the router state and direct data fetching. They outsource state management and business tracking logic to the Application layer.

State Orchestration vs State Management

• Orchestration involves organizing and coordinating application logic and behavior. It focuses on determining when and how application states should change over time with regard to state macromanagement*. Orchestration is all about explicitness and constraints inside your app (both cause predictability).
  • Highlights:
    • Defines finite app's states
    • Designs app's behaviour and constraints it
    • *Macromanages the state - answers WHEN (WHICH) state is supposed to be managed
• Management deals with specific aspects of the application, such as interactions with data. It is concerned with direct manipulation and handling of (module/local) state.
  • Highlights:
    • Defines data containers and interactions with them
    • Micromanages the state - answers WHAT and HOW state is supposed to be managed