Clarification on statefulness

[olipyskoty]

hi team! apologies if this question should be discussed elsewhere. a few of us were just discussing the Paste is not... # section of the Paste docs (under Getting Started > About Paste), and we were wondering if we could get some more clarity or an example of what this bullet point means:

Paste is not...#
- Stateful. While components have encapsulated internal state when necessary (e.g.UI behavior or keyboard interaction), the components themselves are not concerned with application state.

are prototypes generally not supposed to be super interactive? thank you!

[SiTaggart]

Hi @olipyskoty, great question.

To round it out our discussion in our Engineering Focus Time and document it here, we agree this line could be rewritten slightly to be more explicit in what it means.

For that one line, we are only talking about the components themselves that we ship to the consumer. We want our components to be stateless where ever possible. Pure render only components, that know nothing about where they are, what data they are displaying, what the current state of the application is in. etc. This keeps our components as flexible as possible as they aren't tied to any one product, screen, or location.

There are some cases where accessible components can't avoid holding some internal state. Sometimes they need to be aware and store that the user expanded the Combobox, that they pressed the down arrow key and the second item should be highlighted. This is a trade off we make where the ease of creating accessible interfaces out weighs the need for full control. There's a very good write about controlled and uncontrolled components here #570 (comment)

So in relation to prototypes, statefulness is totally fine. You are using stateless components to render a stateful prototype, where knowing what page you're on, what item in the navigation is open is important to be able to effectively test your experience.