Show HN: Clothes shopping app UI built in React Native • Hacker News Board

Re: Show HN: Clothes shopping app UI built in React Native

#41

Post by chrisco255 » Mon, Jul 09, 2018, 4:07 PM UTC

kbcool wrote: post #20

andrewingram wrote: post #15

Earlier quoted context omitted.

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…

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!

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

Re: Show HN: Clothes shopping app UI built in React Native

#42

Post by chrisco255 » Mon, Jul 09, 2018, 4:09 PM UTC

robertAngst wrote: post #25

estsauver wrote: post #2

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.

Re: Show HN: Clothes shopping app UI built in React Native

#43

Post by kbcool » Mon, Jul 09, 2018, 4:12 PM UTC

chrisco255 wrote: post #41

kbcool wrote: post #20

Earlier quoted context omitted.

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!

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

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).

Re: Show HN: Clothes shopping app UI built in React Native

#44

Post by chrisco255 » Mon, Jul 09, 2018, 4:43 PM UTC

kbcool wrote: post #43

chrisco255 wrote: post #41

Earlier quoted context omitted.

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

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…

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.

Re: Show HN: Clothes shopping app UI built in React Native

#45

Post by johnmarinelli » Mon, Jul 09, 2018, 5:27 PM UTC

awinograd wrote: post #6

cubano wrote: post #3

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: * andro…

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.

Re: Show HN: Clothes shopping app UI built in React Native

#46

Post by abritinthebay » Mon, Jul 09, 2018, 5:37 PM UTC

robertAngst wrote: post #26

IBCNU wrote: post #22

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.

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

Re: Show HN: Clothes shopping app UI built in React Native

#47

Post by root_axis » Mon, Jul 09, 2018, 6:22 PM UTC

IBCNU wrote: post #22

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.

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.

Re: Show HN: Clothes shopping app UI built in React Native

#48

Post by anderskev » Mon, Jul 09, 2018, 6:24 PM UTC

jeeeeefff wrote: post #11

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?

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.

Re: Show HN: Clothes shopping app UI built in React Native

#49

Post by pure » Mon, Jul 09, 2018, 7:23 PM UTC

chrisco255 wrote: post #41

kbcool wrote: post #20

Earlier quoted context omitted.

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!

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.

Re: Show HN: Clothes shopping app UI built in React Native

#50

Post by someguy101010 » Mon, Jul 09, 2018, 7:55 PM UTC

Jamieee wrote: post #10

buildbuildbuild wrote: post #5

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.

Excellent resource!