Show HN: Clothes shopping app UI built in React Native | Hacker News Reader

Show HN: Clothes shopping app UI built in React Native

github.com

128 pointsatf1952 comments

I used Redux when it first came out, but now use Mobx as it's just... easier and has less boilerplate. Also it's easy to extend into a reframe-like pure function state management system if you want to avoid passing around objects/inheritance.

My new note to self:

Dont read threads about the stack I'm dealing with.

It will only make me question everything.

So true. I must start doing this as well. I recently started picking up momentum on my React-Redux skills. Constantly reading various opinion pieces (irrespective of whether they are supported/non-supported) are tempting me to take a look a look at (or evaluate) other libs/frameworks.

If it helps, I’ve used Redux in a couple production apps and loved it. Boilerplate can be a bit tedious at times, but in exchange you get a lot of sanity and clarity in your code.

Mostly it just makes me think people have not actually used what they complain about.

Both are usually unnecessary, just pass down functions that call setState as props. That method works for 95% of problems and has the added benefit of being idiomatic react, thus making it easier to read, maintain and reason about. There are some rare cases where something like redux makes sense, e.g. you're hooked into some kind of streaming wire protocol and your UI needs to make many updates in real time based on a variety of diverse messages streaming over the wire. Most of the time though, these opinionated state management solutions are overkill.

I love Mobx. It was fun and easy to understand specially when I tried to understand the state management. But then I realized Redux is basically easy, two things to understand MapStateToProps and MapDispatch to props and then rest is all easy to follow from there. Then with Redux Saga and it is super fun and many possibilities.

I was surprised to see that this uses React without Redux for state management. I'm aware that Redux is a separate, optional, codebase, but from how people have been talking, it seemed like just about everyone was Redux or bust.

How many production-scale projects don't use Redux? Is this more common than I'm thinking and hearing?

I wouldn't get too excited. This is just a shell app, a few screens, no remote data, only temporal state persistence and nothing really functions (eg no form validation, no payments etc).

I assume it was used for some tutorial?!

Not saying you can't get away with not using redux at all but this isn't an example of that. Try mobx or unstated for simple state management.

Personally my projects tend to use it because I'm used to it. Once you get your head around it the boilerplate is not too much to deal with and it slides in so nicely with react. You just need to think in a functional way.

Also features like redux-persist make it powerful. You wouldn't believe the number of apps released on the stores using RN that don't persist state and simply restart when the phone runs out of memory or gets rebooted.

Heh, when I saw UI, I was thinking-

So what?

Javascript, RN, flux, elements, etc... there are soo many ways to make it pretty. That was the whole point. Pretty for android and ios.

The redux tutorial is awful, you dont run the program until the very end. Needless to say, it didnt work and I ended up following a medium guide...

Now I'm trying to get redux working with laravel who requires a CSRF token on each post request. Not a big deal, but getting this CSRF token to be submitted doesnt seem to be trivial since it needs to be requested from the php and submitted all at once.

Not complaining because this is just logic and the job, but the difference between a working RN app and a working RN UI is 10 months.

Not sure what Redux would have to do with a CSRF token? That's HTTP logic.

Use jwt instead and treat laravel as a pure api backend.

Every app i've worked on for the last 3 years has fit in one of two categories:

1. Minimal use of Redux

2. Started with Redux, migrating to eliminating Redux.

This has mainly been due to using other technologies for dealing with API data (i'm using Relay, but there are other options), and having relatively little need for client-side state that can't be handled at the component level. When I have needed simple shared state, I just use the context API. If I absolutely needed a lot of client-side shared state, I might still consider Redux, but would also strongly consider client-side GraphQL extensions (both Relay and Apollo support these) so that everything follows the same patterns.

Is Apollo ready for true client side caching these days? I tried it on an app earlier this year with the belief that it would allow me to skip redux and simply keep client state synchronised with the server but without having to load it every time and walked away disappointed. The vision is great though!

As far as Apollo Client is concerned, I don't really know. I keep up-to-date with what's going on, but haven't really used it. Everything i've heard suggests there shouldn't be a problem, but Apollo is really good at marketing.

For Relay you're basically given no caching out of the box, but you can implement it by essentially hijacking the store's garbage collection to use an LRU cache instead of immediately evicting data when its dependents unmount. The developer experience for client-side schema extensions is similarly immature, but it is possible.

If you need all this functionality and aren't comfortable diving into the trenches, you'll have an easier time with Apollo (assuming everything works as advertised).

What were your negative experiences with Apollo? Been using it for a year and haven't had any issues.

I started with apollo-client on a new app, but switched to using ngrx and turning off apollo-client caching (basically using apollo-client as a fancy graphql request library - I should probably just use apollo-link directly). My main problem was that it felt like it required both developers and components to have too much knowledge of the individual queries that the app was making. Instead of writing an app that happened to use graphql, I felt like I was writing a graphql app.

An example of that is updating the state after mutations that modify lists (e.g. creates or deletes). It's up to the developer to remember all other queries that could be affected by a mutation and to update them manually after the mutation completes (more info: https://github.com/apollographql/apollo-client/issues/3505 and https://www.apollographql.com/docs/angular/features/cache-up...). If you add a new component that performs a query that could be affected by a previous mutation, you have to remember to also go back to that mutation and update your query from it. With ngrx (or redux), the consistency is baked in, and part of the beauty of it is that if you update the state, anyone who happens to be reading that state will get updated automatically.

I can see where updating the cache in all the right places for complex architectures could get hairy. For my own personal project, I'm using GraphQL Subscriptions to listen for mutations and piping those events directly to the client, which then updates the cache accordingly. I get that's not a solution for everyone as it would largely depend on your backend architecture having support for subscriptions.

Not negative as such, just didn't hit the mark that their marketing material was promising.

It's great for pull down refresh lists etc and I even had success doing dynamic insertion when an item in another view was updated (though I had to use a different graphql client to do the inserts ironically) but it was sold as replacing all need for redux for example for state management and that it would sync seamlessly with a graphql backend and unfortunately (maybe it was me) couldn't work out how to do that so ended up using redux as well.

What I was lead to expect is that you subscribe to a store which is dynamically filled and updated by Apollo (which handles synchronising local and remote and loading from scratch etc).

It might have had to do with the fetchPolicy that was in place. By default, Apollo aggressively uses local caching. But this is not always good. Ideally you could just subscribe to GraphQL subscriptions which would update your local stores, but I understand not all backend architectures are wired up that way. https://www.apollographql.com/docs/react/advanced/caching.ht...

Apollo has more advanced configuration options, and I think they're confusing to grasp at first. But I do think Apollo cuts down on the amount of state management you need to do for a typical app by about 2/3rds or more.

I personally used redux one time on a project and said, never again.

I wish, but I think my project is too big for me to avoid it.

Try MobX

Or unstated.

https://www.quora.com/Can-you-build-a-complete-react-applica...

You can absolutely build React apps without Redux, often times however I find myself using Redux the most while communicating with the Api (Call out to the API, get some new data, put it into the Redux store, App rerenders) so if this is just a shell, then I'm assuming it would be fairly easy to get away with not using it.

We have three RN production apps, only one is using Redux because the developer was familiar with it, not because we necessarily needed it. The other two are using Apollo Link for client-side state.

Working on a new production app right now that does not use Redux, I do not plan on backwards integration either. For reference, our team does have two applications that utilize Redux.

We don't use redux. We are happy using js-data with a rest backend right now. We going to try graph-ql soon.

I love exploring structure and approach in codebases written recently, it’s one of the best ways to learn a new language or mentally refresh on what new libraries and tools exist.

Anyone know of good resources or proper search terms for “show me fully executed applications built on X language/stack within the past year”

I've found realworld.io is pretty good for working examples of different stacks. Maybe not as up to date as you're looking for, but a good start for new languages and frameworks.

Thanks for the great tip, Jamieee! realworld.io looks worthwhile.

This is exactly what I couldn’t find. Thank you!

Excellent resource!

This is really cool! Thanks for releasing it, I love seeing how other people structure medium sized applications.

Why'd you pick react native?

Works on android and IOS?

Is there anything else that does both?

Yes, there's Xamarin, Flutter, NativeScript, etc.

Not to be cheeky, but why not just react?

Isnt react web only?

But the web runs on all of those platforms, and there are a ton of ways to wrap a browser view into a native "wrapper" to put in the app store (including react native)

Right, but web looks like web even if you wrap it.

RN is supposed to feel like an Android or Iphone app.

(Btw, someone prove me wrong because I have a full blown working website/database and the front end is RN and I'd love to stop because I hate front end auth and multiple platform...)

Onsen UI could maybe tackle that (I'm working with it) - gives you material or Cupertino look on the fly. Still caveats with Cordova vs Native but it's alot less work...

Hi Atef. Nicely done. Good screen designs.

I'll check out your code soonest. And I'll try to dig up an android device, so I can try your demo.

I just wanted to acknowledge your effort and good taste, since everyone else got distracted by the framework wars.

Without revealing too much about me, since this is my anon account, I work in a nearby field. If you wanted to pursue this domain (fashion), I encourage you to focus on product discovery. Either something novel, or excellent execution and refinement of current solutions.

I don't mean personalization, recommenders. (Unless you have something awesome.)

Rather, I mean UX for better forraging behavior. By analogy, the digital equivalent of wandering around in libraries, museum, or retail. Whatever that looks like.

Happy hunting.

I feel like Redux has been the love child of the React community (not necessarily HN) and I have felt like a crazy person for not loving it and clinging to AltJS and then to MobX. Good to see a lot of other MobX fans in this thread.

I am wrong to wonder why this doesn't run in a browser, or does it?

I was under the impression React uses the browser DOM (or virtual DOM of course) to render its components...wouldn't that mean it can run on the desktop in a browser?

This project is using React Native which is slightly different from ReactDOM (commonly referred to as just React/ReactJS).

In the past, ReactJS and ReactDOM were completely interchangeable. However, some time ago now React split the DOM specific parts of the library into ReactDOM which allowed the non-DOM specific parts of the library to be shared more easily across different rendering targets. Some examples:

  * android (via react-native)
  * ios (via react-native)
  * canvas https://github.com/Flipboard/react-canvas

Since the release of React Native there have been a couple of interesting projects that allow developers to use the same APIs as React Native, but rendering to the DOM instead of android/ios native views.

https://github.com/necolas/react-native-web is a great production ready lib but requires a bit of setup to get it working with a react-native project.

https://github.com/vincentriemer/react-native-dom is an extremely cool experimental idea to bring react native projects more seamlessly onto the web. It's still in early stages and has some significant tradeoffs compared to react-native-web. For one, it includes a webassembly implementation of Yoga (https://yogalayout.com/) which makes layout much more consistent among ios/android/web but at the cost of delivering more JS upfront to the browser.

another cool custom renderer using React is this: https://github.com/toxicFork/react-three-renderer-fiber

it wraps the React API over three.js. Unfortunately it's a very wip-ish state, but I think it has a lot of potential.

You can just imagine that the function that would normally generate DOM elements with something like document.creatElement(‘div’), has been replaced with boundObjectiveCCreateNativeUIView() ... there is no platform check for the browser, so in the render step it will create native UIViews or whatever Androids native View primitive is.

It runs JS in the target platform's JS engine (iirc in a background thread) and renders the UI using the target platform's components. This gives it the flexibility and development speed of a webapp, but the UI performance of a native app. In theory anyway.

Compare also with Flutter [0], a new competing application development stack from Google with a similar architecture (= components all the way down) and development experience (= live reloads), but which will in production compile everything to native (instead of interpreting JS).

[0] https://flutter.io/

I'm not exactly sure either, but if I understand correctly, react native is actually not running under web view, hence called "react native"?

You are correct, it interacts directly with native components - it doesn't render in a webview.

very nice! this is one of those "git clone and walk away" moments, because something this good and free won't be around forever

Reply on news.ycombinator.com