Dont read threads about the stack I'm dealing with.
It will only make me question everything.
How many production-scale projects don't use Redux? Is this more common than I'm thinking and hearing?
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.
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.
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.
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).
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.
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).
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.
Anyone know of good resources or proper search terms for “show me fully executed applications built on X language/stack within the past year”
Why'd you pick react native?
Is there anything else that does both?
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...)
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.
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?
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
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.
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.
Compare also with Flutter , 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).