Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Architecting UIs for Change

joreteg.com

Post reply on HN
Print view View original

21–29 of 29 posts

Re: Architecting UIs for Change

#21

Post by HenrikJoreteg »

janic wrote: post #15

I think there actually is an issue with our data models. REST apis have moved a lot of the complexity of data fetching on the client apps since it is basically a 1 to 1 mapping of the database schemas. Making connections between the different data types becomes a frontend concern which is not ideal since frontend has to deal with partial data and full network latency / failures. Thinking in graphs and query languages…

I use graphql extensively as an API for apps I've built this way. But I don't feel like it really fundamentally changes very much in the client (other than much more efficient data fetching). But you still have to compose the data into the view the client is trying to render. Defining data requirements in components is nice in theory, I just personally don't know of any examples where this approach is being used successfully at scale. There may be examples I don't know of. Do you know of any successful large Relay apps?

Re: Architecting UIs for Change

#22

Post by lioeters »

pests wrote: post #17
dovel wrote: post #8

Earlier quoted context omitted.

Do you store all UI state in redux as well as all 'resource state'? Phrased as an example... If you store a JSON object that can be edited in your store do you also store a Boolean value for whether the dialog is open that can be used for editing that JSON object?

My determination is: Do I want this state to survive a page reload, new browser session, or coming from a bookmark? The value in a drop-down box in some random form? Non-global state. The main page active tab that they were probably reading? Global state. Scroll position? Global. Tooltip Position? Probably not useful, non-global. Something like a dialog or modal depends on the situation of how important it was and if…

I agree with that logic, I think I've encountered every one of those cases.

That makes me see that there isn't a "god" object like the article calls it, that holds all of the app state. There's the root state shared throughout the app, and then each page or component can have its own encapsulated state.

Ideally I like to also keep page- or component-specific state+actions decoupled from their views, functional and testable independently - but often I start/keep them in the component class (and maybe soon hooks).

Re: Architecting UIs for Change

#23

Post by smoyer »

pests wrote: post #17
dovel wrote: post #8

Earlier quoted context omitted.

Do you store all UI state in redux as well as all 'resource state'? Phrased as an example... If you store a JSON object that can be edited in your store do you also store a Boolean value for whether the dialog is open that can be used for editing that JSON object?

My determination is: Do I want this state to survive a page reload, new browser session, or coming from a bookmark? The value in a drop-down box in some random form? Non-global state. The main page active tab that they were probably reading? Global state. Scroll position? Global. Tooltip Position? Probably not useful, non-global. Something like a dialog or modal depends on the situation of how important it was and if…

You can also apply the command pattern in some cases and store the undo redo state globally.this at the global store can be generic and the previous specific state will be part of the saved commands. (More applicable to SPAs).

Re: Architecting UIs for Change

#24

Post by lioeters »

pests wrote: post #19
lioeters wrote: post #10

Earlier quoted context omitted.

Hmm, typically, I do store "UI state" (or parts of it) in the top app state if that UI state is shared among pages/routes. In your example, if I want that dialog state to be "persistent" - say, the user goes to another route then comes back, if the dialog state should be kept. Otherwise, I store them in the route component's state, which gets created anew every time. But your question makes me think, if I store any U…

Unless you have code that depends on state that supposed to be kept UI-only. Then when you expand to an API or CLI interface the web state being tracked no longer makes sense and might be extra ram or loading time.

Well, at least theoretically, the way I organize state management allows me to pull in "slices" of app state/actions (or even moved into shared libs/modules), to compose a smaller subset for an API or CLI. So the latter can choose to not include any of the UI-related state.

In practice I haven't used it so much, but I like the idea of treating the UI as just another render target / consumer of app state/actions. It enables "remote control" of the app logic, makes testing simpler, and allows reuse for various interfaces like CLI, API, maybe React Native too.

Re: Architecting UIs for Change

#25

Post by cuddlecake »

HenrikJoreteg wrote: post #21
janic wrote: post #15

I think there actually is an issue with our data models. REST apis have moved a lot of the complexity of data fetching on the client apps since it is basically a 1 to 1 mapping of the database schemas. Making connections between the different data types becomes a frontend concern which is not ideal since frontend has to deal with partial data and full network latency / failures. Thinking in graphs and query languages…

I use graphql extensively as an API for apps I've built this way. But I don't feel like it really fundamentally changes very much in the client (other than much more efficient data fetching). But you still have to compose the data into the view the client is trying to render. Defining data requirements in components is nice in theory, I just personally don't know of any examples where this approach is being used succ…

Probably Facebook, but I'm not entirely sure, since they didn't start with GraphQL but rather created it along the way

Re: Architecting UIs for Change

#27

Post by t1mmen »

We started using ~this selector pattern for timelyapp.com almost two years ago, and have found it tremendously helpful.

Anytime we’re reading data from Redux, it’s via a selector (usually a composition of multiple selectors).

For data fetching, we use a slightly different approach, but same principle: An xhrCacheBuster string that, when changed, fires a thunk action. Query params/payload is determined via a selector in the thunk.

We use similar patterns to “sign” expensive-to-render things, then compare the renderCacheBuster string in shouldComponentUpdate. Same with virtualized lists (named virtualizationCacheBuster)

Re: Architecting UIs for Change

#28

Post by janic »

HenrikJoreteg wrote: post #21
janic wrote: post #15

I think there actually is an issue with our data models. REST apis have moved a lot of the complexity of data fetching on the client apps since it is basically a 1 to 1 mapping of the database schemas. Making connections between the different data types becomes a frontend concern which is not ideal since frontend has to deal with partial data and full network latency / failures. Thinking in graphs and query languages…

I use graphql extensively as an API for apps I've built this way. But I don't feel like it really fundamentally changes very much in the client (other than much more efficient data fetching). But you still have to compose the data into the view the client is trying to render. Defining data requirements in components is nice in theory, I just personally don't know of any examples where this approach is being used succ…

Artsy is a great example since their code is open source https://github.com/artsy/emission. Facebook does use relay in a lot of products. I’ve also seen a talk about how airbnb uses Apollo in a similar way as relay and collocate fragments with components.

If I take the example in your article I think this model solves the problem nicely. Let’s say you want to include a cart component that was created by a completely different team, in another part of the app, all you have to do is to add the fragment to the query that already exist in your screen and everything just works thanks to composition.

Then when someone adds features to the cart and for example fetch the full list of items then all screens that render that cart component will have their query update accordingly since they include the cart fragment.

Re: Architecting UIs for Change

#29

Post by pests »

lioeters wrote: post #24
pests wrote: post #19

Earlier quoted context omitted.

Unless you have code that depends on state that supposed to be kept UI-only. Then when you expand to an API or CLI interface the web state being tracked no longer makes sense and might be extra ram or loading time.

Well, at least theoretically, the way I organize state management allows me to pull in "slices" of app state/actions (or even moved into shared libs/modules), to compose a smaller subset for an API or CLI. So the latter can choose to not include any of the UI-related state. In practice I haven't used it so much, but I like the idea of treating the UI as just another render target / consumer of app state/actions. It e…

I do agree for the consistent mental model.

I've been playing around switching web-apps and other user programs between devices on a single-ususer facing kubernetes system. Part of that relies on all state being sent to the server for distribution if a device switch happens.

I also have played around with a wrapper functions and that can bubble any callback/hook up to the data for further processing. The client no longer worries about sending actions. The server spys on client actions and performs actions on their behalf.

I plan on posting a blog post about the his soon.

Post reply on HN