ElanoryaJewelry AI · Store screen
A placeholder stands where the price should be
The app holds no price of its own. Every figure on the store screen is text the store returned for that device and account, so when nothing comes back the screen shows a placeholder and the purchase control stays closed.
Where the number on this screen comes from
The store screen combines two things that arrive separately. The list of items is pulled from the server catalogue, and if that fetch does not succeed the app falls back to a list it carries itself, so the screen is not left without rows. The price beside each row is a different matter: it is taken from the offer the store provider reports for that device, and there is no second place to get it from.
That is why a gap can open on one side and not on the other. The fallback list carries item identifiers and display details; it does not carry a price and cannot stand in for the store. When the store returns no offer for an item, the app writes a placeholder in the position where the price would go and leaves the purchase control closed, rather than printing a figure it has not been given (apps/jewelry-mobile/src/app/store/index.tsx).
The rule behind the placeholder runs in one direction only: no price is preferred to a price that might be wrong. The same rule decides a narrower case. When the billing period the store reports contradicts the period the screen would print alongside it, the offer is not used at all - no figure is shown and that item cannot be bought. A store that reports no period is not treated as a contradiction (features/purchases/subscription-period.ts:69).
What a row on this screen is made of
Three facts describe everything the screen does with the data it receives, and everything it declines to do without it.
- The item list has a fallback. The price does not.
- A failed catalogue fetch is absorbed by a list held in the app, so rows still appear. No equivalent exists for the price: it comes from the store's offer or it does not come at all.
- The placeholder marks a value, it does not report a fault.
- It stands in the position of a value the app was not given. The app does not estimate, round, convert, or reuse an earlier figure to fill that position.
- A closed purchase control follows from the same condition.
- Where there is no offer, there is nothing to purchase against, so the control stays closed beside the placeholder.
The same row, with an offer and without one
Nothing else on the row changes. The difference is confined to the price position and the control beside it.
| Part of the row | Store returned an offer | Store returned nothing usable |
|---|---|---|
| The row itself | Drawn from the server catalogue, or from the app's fallback list | Drawn the same way; its presence is unaffected |
| The price position | The store's own text for that device and account | A placeholder, with no figure of the app's own |
| The purchase control | Open | Closed |
| A re-check on this screen | None | None |
Why there is nothing here to try again with
The store screen has no manual re-check. No control on it asks the store for prices a second time, and that absence is not a passing state of the screen - it is how this surface is built.
Two things do cause loading, and they are worth telling apart. The item catalogue is fetched once each time the screen is entered, so leaving and returning does renew the list. Offers are loaded when session or account state changes, which entering a screen is not. That is why a placeholder can survive a departure and a return: the part that was fetched again was never the part that was missing (apps/jewelry-mobile/src/app/store/index.tsx).
Which reading fits what you are looking at
Each row below is a shape the screen can take, and the reading the app's own behaviour supports.
| Situation | Choose | Why |
|---|---|---|
| Every row shows a placeholder where a price belongs. | Read it as the offer side being unavailable for this device and account, not as the items being gone. | Rows are drawn from the catalogue or from the app's fallback list, and the fallback carries no price at all. |
| One row shows a placeholder while others show figures. | Read it as that single offer being unusable, not as the screen failing. | An offer is dropped on its own when the billing period reported with it contradicts the period the screen would print. |
| The purchase control does not respond next to a placeholder. | Do not wait on this screen for it to open. | The control is closed because no offer text was returned, and nothing on this screen re-checks for one. |
| You leave the screen, return, and the placeholder is still there. | Treat the return as having renewed the list, not the prices. | Entry re-fetches the item catalogue; offers are loaded on a change of session or account state. |
What a placeholder is easily mistaken for
Three readings the screen invites, and what the app's behaviour actually supports.
That the item has been removed.
The row is present, which is a statement about the list, not about the offer. The list has a fallback path that does not depend on the store at all.
That the app is holding a price back until something finishes loading.
There is no held figure. The app writes a placeholder because it has not been given a value, and it has no second source to draw one from.
That opening the screen again is a way of retrying.
Entering the screen fetches the item catalogue. It is not a session or account change, which is what causes offers to be loaded.
Questions this page leaves open
Each of these sits outside what the store screen's own behaviour can settle.
- No price, currency, credit amount, discount, pack name or plan name appears here, in an example or in any other form.
- How often the store returns nothing usable, and under what conditions on the store's side, is not readable from the app.
- What the store provider does internally, how its payment sheet opens, and how refunds or renewals proceed are not this page's subject.
- What happens after a purchase has started - including a purchase that cancels, waits, or fails - is settled elsewhere and is not described here.
- What restoring purchases does, and the state of the control that offers it, belong to a separate page.
- How credit appears on the server after a purchase, and what the wallet or transaction history screen shows, are outside the surface examined here.
Questions
Is the app broken when a price is missing?
A placeholder is the app working as built. The price text is only ever the offer the store reported for that device and account; when there is no offer, the app writes a placeholder rather than a figure of its own, and keeps the purchase control closed.
Is there any way to make the app check prices again?
Not on this screen. There is no manual re-check. The item catalogue is fetched once on each entry to the screen, and offers are loaded when session or account state changes.
Why does one item show no price while the others do?
An offer is discarded on its own when the billing period the store reports with it contradicts the period the screen would print. In that case no figure is shown for that item and it cannot be bought.
If the store cannot be reached, where does the list of items come from?
The list is pulled from the server catalogue, and if that fetch does not succeed the app falls back to a list it carries itself, so rows still appear. That fallback holds item identifiers and display details only; it never supplies a price.