Checkpoint: Three Kinds of State Behind One Screen
OpenStock can show a unified stock page because several kinds of state are being brought together at once. The user has an identity and preferences; the application has normalized responses and presentation rules; external providers have changing prices, charts, articles, and source availability. This checkpoint turns those relationships into a practical model: classify what a screen is showing, who owns it, who updates it, and where it can fail.
The screen is unified; the state is distributed
A reader sees one application shell, but no single system owns everything that appears inside it. A quote may be fetched from Finnhub. A chart may be rendered by TradingView. A sentiment snapshot may contain responses from Adanos. The decision to place those views beside one another belongs to OpenStock. A watchlist membership and alert belong to a user record in MongoDB. The screen is the meeting point, not the source of every fact.
That difference explains why OpenStock’s central problem is orchestration. The application must make unrelated inputs feel coherent without erasing their different meanings. It must carry a symbol from search into a chart, from a chart into a watchlist, and from a watchlist into news or alert evaluation. At each transition, some state is carried forward, some is transformed, and some remains outside the application’s control.
The simplest way to see this is to separate three categories.
Provider state is what an external service currently knows or can render. It includes a quote, a company profile, a news response, a TradingView chart, or an Adanos source row. Provider state can change independently of OpenStock. It can be delayed, rate-limited, incomplete, unavailable for a symbol, or governed by a commercial tier.
Application state is what OpenStock does with those responses. It includes a cache or revalidation decision, a normalized search result, a validated article, a translated exchange symbol, a selected set of news items, a composed stock page, or a sentiment alignment label. Application state is where the project expresses policy. It decides what counts as usable, what can be shown together, and which fallback to use.
User state is what gives the workflow continuity. It includes a session, onboarding preferences, a saved symbol, an alert condition, and activity timestamps. It is durable or semi-durable in a way a provider response is not. A provider can change a quote without removing a user’s watchlist relationship; a user can remove a symbol without changing the public market data.
These categories can interact without becoming interchangeable. A sentiment alignment label is application output derived from provider inputs; it is not a provider fact. A watchlist item is user state that refers to a provider symbol; it is not proof that the user owns shares. A cached profile is application-managed reuse of provider data; it is not a fresh quote.