Slaying a UI Antipattern in React – JavaScript Inside – Medium

How to solve an UI anti pattern with React ? A great post by @sharifsbeat  #ReactJS

  • Setting the items to null instead of an empty array creates even more problems so that won’t help either.Stefan Oestreicher, Slaying a UI Antipattern in FantasylandSo we have to manually keep track of the current data status, making sure we don’t forget to set the correct loading, error and data…
  • Forgetting to keep the state in sync leads to a false representation in the UI.In Slaying a UI Antipattern in Fantasyland we are represented with a different way to think about the problem:type RemoteData e a = NotAsked | Loading | Failure e | Success aWe might have different states…
  • By modelling all possible states, we can resort to using daggy f.e., which enables us to handle the possible outcomes.const RemoteData = daggy.taggedSum({ NotAsked: [], Loading: [], Failure: [‘error’], Success: [‘items’],})// in our constructorthis.state = { items: RemoteData.NotAsked }(* Taken from Slaying a UI Antipattern in Fantasyland)By now we should…
  • Loader /What if we could take all these ideas and wrap them inside a React component, which takes care of all of this, without having to manually take care of the low level stuff.Michael Jackson wrote about the render-props concept in his Use a Render Prop!
  • Now we don’t have to think about if the UI is representing the proper state, all we need to do is tell Loader / what we want to see if the component is loading, has an error and has any data.Now that we have an idea of how Loader should…

The following write-up is based on Stefan Oestreichers blog post Slaying a UI Antipattern in Fantasyland which was originally influenced by Kris Jenkins excellent how Elm slays a UI antipattern. Just…

Slaying a UI Antipattern in ReactSolving a well known a UI problem with ReactThe following write-up is based on Stefan Oestreichers blog post Slaying a UI Antipattern in Fantasyland which was originally influenced by Kris Jenkins excellent how Elm slays a UI antipattern.Just a quick overview of the anti-pattern we’re talking about here. Typically you might see data represented like the following i.e.:const data = {loading: false, errors: null, items: []}Here’s how this is described by Stefan Oestreicher:But of course it’s easy to forget to check the loading flag or maybe you just can’t be bothered right now because of time constraints and “will do it later”. It also just makes for awkward code everywhere. Setting the items to null instead of an empty array creates even more problems so that won’t help either.Stefan Oestreicher, Slaying a UI Antipattern in FantasylandSo we have to manually keep track of the current data status, making sure we don’t forget to set the correct loading, error and data state. It’s very easy to forget to set the loading to true to false, if you think about it. Forgetting to keep the state in sync leads to a false representation in the UI.In Slaying a UI Antipattern in Fantasyland we are represented with a different way to think about the problem:type RemoteData e a = NotAsked | Loading | Failure e | Success aWe might have different states to represent in the UI, i.e. NotAsked (we haven’t done anything yet). By modelling all possible states, we…

Slaying a UI Antipattern in React – JavaScript Inside – Medium