Reshaping API databeginner
The shape an API returns is almost never the shape your UI wants; turning snake_case rows with flags into the objects your components render is most of frontend work.
A weather provider’s field names — main_temp_k, w_cond_str_v2, precip_mm_h — have leaked into the code that displays them. Put one adapter between the two so the day the provider renames a key, one file changes.
See alsoThe gateway’s JSON, parsed in the business logicThe same boundary in C#, where the seam is an interface and the swap is a second class.
Renaming a provider key is a one-line change in one file.
Published in full, before you start — every point is one of these and there is nothing else. Each one runs your code; it is not a search for keywords.
The shape an API returns is almost never the shape your UI wants; turning snake_case rows with flags into the objects your components render is most of frontend work.
A vertical slice keeps one feature — its endpoint, its validation, its data access — in one folder, so changing checkout means opening one place instead of four layers.
A cart that can hold the same product twice, or a quantity that can go to zero, is a bug you will chase through the UI forever — the rules belong in the data layer.