Comment by wwalser | Hacker News Reader

Comment by wwalser | Hacker News Reader

It sounds like you're new to both React Native and the JavaScript ecosystem. I can imagine this being very frustrating for someone regardless of their general programming chops. I happen to be on a React Native project at work right now. Hopefully I can provide a viewpoint that is helpful and give direct answers to some of your questions.

One thing that would be helpful to understand that's missing from the OP, what are you building?

> However, seeing the differences between react and react native, this seems overstated.

I'm actually not sure which specific differences you're referring to. Perhaps you can clarify?

> It was recommended to use javascript and react/react native so I only needed to program once.

It's possible to use RN to build an application which runs on both Android and iOS from a single code base. This is possible with a few other environments but none are (IMO) quite as good at affording for a truly native look and feel including dropping down into native code when necessary.

Building a really great app is still a grind on execution and perfecting small details is a chore. The standards of quality in the mobile app world are high which leads to average users having higher standards than they might with desktop or web applications.

> What were the other benefits?

For people who enjoy working in JavaScript, the fact that you can write native applications using mostly JS is a benefit.

Some products benefit from being able to share code between a web product and a RN application is a big boost in productivity. I've personally saved hundreds of hours leveraging this. It's not a 1:1 swap but it's close enough to lower the mental burden compared to creating something from scratch.

> I thought there was already built components/libraries I could drop in for data management.

There are lots of data management libraries for React. Most can be used in a RN app. Maybe the community resources section of the React documentation will be helpful: https://reactjs.org/community/model-management.html

I can provide specific recommendations if you can describe specific needs. Like most ecosystems deciding which tool to use in which situation is a skill which builds up with experience.

Here is too much information, but this is how I spend my evenings now...

Goal is a finance tech app, although I probably just need a pretty front end, and I can do stuff manually in the background (like invest money, wire transfers, etc...).

I do have some database experience, writing to mysql. Was planning on doing that using LAMP, because I have experience already.

Features needed:

>write to database(should be easy with my previous experience)

>Usernames/passwords(I am actually clueless how to start doing this, I have Wordpress if needed)

>Accept payments(but again, I can probably do this through wordpress if its too time consuming).

Other specs, since its finance and people are going to be putting money into it, its gotta look and feel good. I'm willing to invest many months into building this to be perfect. However, progress feels slow since I'm learning the new javascript react-native syntax.

Any tutorials you recommend? Working through the facebook tutorial right now.

last trivia question- I was considering using Reflux, but I saw an article saying reflux is dying. I've heard facebook is especially brutal with changes.

> I was considering using Reflux

Redux is the de facto standard now in that space. It seems to have "won".

See https://stackoverflow.com/questions/36326210/what-is-the-cor... for further discussion.

Nope, sorry those days are over. Redux is on it’s way out, please refer people to this:

https://react-etc.net/entry/rip-redux-dan-abramov-announces-...

This article puts a pretty hard spin on what actually happened: Dan Abramov did not announce a "replacement for Redux", nor is he developing a "Future Fetcher" library. The React team is working on a feature that defers state updates until an asynchronous operation is finished, but we don't know how it'll fit into existing state management solutions.

Here's the official blog entry and talk where these features were announced: https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-...

I'm a Redux maintainer, and that post is utterly and completely wrong in every way.

What Dan Abramov showed at JSConf Iceland was a pair of demo apps that illustrated upcoming improvements in React related to async rendering and data cache handling. Those features have no bearing on whether or not you use Redux, and are certainly not "replacements" for Redux. The linked tweet from Kent C Dodds was a joke tweet in a joke discussion thread, and the author of that site has repeatedly shown that either they don't understand the React world, they are very bad at writing and researching, or that they're just flat-out trolling.

There's certainly been plenty of discussion lately about when it's appropriate to use Redux, and I'd agree that many people are told to use it blindly without understanding what the tradeoffs are. It's also true that the new React context API (available in the upcoming React 16.3 release) means you won't need to pull in Redux _just_ to avoid "prop-drilling" data all the way down the tree.

However, Redux is absolutely not deprecated and not being replaced, and the React team isn't in charge of Redux anyway. Dan Abramov and Andrew Clark, the co-creators, are both now part of the React team, and are no longer active maintainers - Tim Dorr and I are. We _do_ still talk a lot about what the future plans are for Redux, and in fact right now we're working on updating the React-Redux library so that it properly works with the "async rendering" capabilities once those are released (see discussion [0] and an early WIP PR I filed yesterday [1] ).

[0] https://github.com/reactjs/react-redux/issues/890

[1] https://github.com/reactjs/react-redux/pull/898

With that said, in many circles I frequent there seems to be growing consensus that Redux just isn’t that useful, and in many cases ends up being a tar pit of boilerplate code that slows down development. Any project complex enough to require Redux should have enough talent on hand to basically write their own version of Redux for their purposes. Redux is such a small library and not enough people seem to be looking under the hood to realize there’s nothing magical about it.

If this is a growing perception amongst the developer community, it’s only a matter of time before it begins to impact the Redux’s relevancy.

I'll agree with the "nothing magical" statement, but I disagree with most of the rest of that comment.

Certainly there's nothing "magical" about Redux. After all, the core `createStore` function can be written in about 25 lines if you leave out error handling, and the entire core lib in about 100 lines [0]. React-Redux does have a ton of optimization work internally, but conceptually it's pretty simple too - components subscribe to the store, call getState(), extract what they need, and re-render [1]. And that's the great thing: Redux is, as its tagline says, "a _predictable_ state container" - there _is no magic_ involved.

What a lot of people don't seem to realize is that the Redux core is a _starting point_. One of my favorite quotes is:

> "Redux is a platform for developers to build customized state management for their use-cases, while being able to reuse things like the graphical debugger or middleware"

We encourage Redux users to use whatever abstractions are appropriate for their own applications, including writing their own. In addition, Redux was designed from the ground up to be extensible [2]. As a result, the Redux ecosystem has exploded. My Redux addons catalog [3] lists somewhere around 2000 Redux-related libraries, utilities, and tools, ranging from action/reducer generation utils to side effects management addons to abstractions for fetching data from REST APIs.

I've seen dozens of "Redux, but.." knockoffs. Most of them wind up throwing away the key design decisions that make Redux special. In particular, the concepts of plain object actions and reducer functions are what truly enable time-travel debugging and easy serialization of state.

My current estimate is that somewhere between 50-60% of React apps currently use Redux. Redux has gained adoption in the Angular, Ember, and Vue communities as well, and inspired dozens of similar libraries, like NgRx, VueX, and more.

Sure, I expect that some of that "market share" will slip over time, especially with the release of the new React context API soon. But, I also feel safe in saying that Redux will be around for a long time.

[0] https://gist.github.com/gaearon/ffd88b0e4f00b22c3159

[1] https://gist.github.com/gaearon/1d19088790e70ac32ea636c025ba...

[2] http://blog.isquaredsoftware.com/2017/09/presentation-might-...

[3] https://github.com/markerikson/redux-ecosystem-links

> last trivia question- I was considering using Reflux, but I saw an article saying reflux is dying. I've heard facebook is especially brutal with changes.

Not dying, just shrinking usage area. The community feels that it got overused. Kinda like you don't buy an Oracle license to make a todo app. So there's some backlash in the blogs. Upcoming versions of React include better/expanded global state management (the context API). Some of what people use Redux for now will be better served by that API.

Redux also doesn't tie in with any specific database or backend. As other vertically integrated solutions take shape, that will also cut into Redux's usage. At facebook, this would be Relay, a GraphQL library. A lot of people are excited about using a query language to talk to the server. It makes versioning and supporting multiple generic apps/features much simpler. Writing specific web service APIs locks you in if you need to support old client versions, etc. You end up with fetchUserInfo(), fetchUserInfo2(), fetchUserInfo3(), etc to avoid breaking clients. Ugh.

With respect to the last point: redux isn’t dying. I’d posit that most articles and blog posts written about front end technology are highly inaccurate marketing pieces designed to get clicks :)

Probably misread that (or they miswrote): reflux != redux.

I would agree with both statements: redux certainly isn't dying, though reflux may be.

Had to verify it was you, "peter" is out of character. :p

I'll point you to:

- My list of suggested resources for learning React: http://blog.isquaredsoftware.com/2017/12/blogged-answers-lea...

- My list of suggested resources for learning Redux: http://blog.isquaredsoftware.com/2017/12/blogged-answers-lea...

- My React/Redux links list, which has categorized links to articles, tutorials, best practices, and much more: https://github.com/markerikson/react-redux-links

Also, come by the Reactiflux chat channels on Discord! It's a great place to ask questions and learn. The invite link is at https://reactiflux.com .

Thank you!

> Goal is a finance tech app, although I probably just need a pretty front end…

Sounds like an interesting, ambitious project, I wish you the best :).

For building a finance app, you're completely right to build just a pretty front end. Since you can't trust the client, most everything of substance is going to be done on the backend.

> write to database

You want to send messages to a backend which are validated for sanity and safety then written to a database. What you're after is very likely a simple http client. Documentation is here: https://facebook.github.io/react-native/docs/network.html

> Usernames/passwords

You want an authentication screen that submits to a backend for validation. The backend creates a session which can be managed in a myriad of different ways. Making decisions about exactly how this works is context dependent. You can manage credentialing, tokens, authentication and authorization, someone else can manage it for you, you may oAuth with a platform that you're building on top of etc.

> Accept payments

If people are paying you for a product or service, Stripe. If people are transferring money to you for financial services, planning or management, they will expect to be able to send ACH/wire transfers without a fee associated. I don't have a foot in this world so I don't really know what direction to point.

> its gotta look and feel good

This can be done w/ RN but (obviously) RN isn't required. If you're more comfortable with the native language of the two platforms (Java & Objective-C or Swift) it may be a more productive use of your time to go that direction.

Unsolicited start-up advice: Don't go out of your way to learn new technology while building a company. There are plenty of "hard parts". Intentionally adding to the litany of hurdles to overcome is a very bad idea.

> Any tutorials you recommend?

Given your past experience, I recommend you work through a single simple tutorial (the Facebook one will do) then start trying to build your app. No reason to solve someone else's made up problems when building your own thing will naturally present plenty of problems.

> Reflux

If you mean "Reflux", I don't know what that is and I'm pretty deep in that world. Probably unnecessary.

If you mean "Redux", it's a very popular, extremely simple state management library. I recommend you try going without it and pick it up if you think it will help later on. Redux solves a specific set of problems that most small applications don't have.

Thank you for the detail.

>You can manage credentialing, tokens, authentication and authorization, someone else can manage it for you, you may oAuth with a platform that you're building on top of etc.

Is there a Stripe of passwords/credentials?

Or something I can google to understand how to get started?

If you’re on a LAMP stack, I assume you’ll use a PHP framework? If so, they will have libraries available that can handle auth for you. Laravel is the big php framework these days. Lots of libraries and tutorials available.

On the payment side of things, Stripe isn’t the only option available. The pro is that it has the fastest Onboarding workflow and a super slick api. The con is that you pay for it.

If you are margin conscious or your business revolves primarily around payments you can do better.

If that is the case for you, build with stripe through MVP stage but keep in mind you may want to swap out one day while building.

I’ve seen some niche businesses save 1% over stripe. That doesn’t apply to everyone but is frequently overlooked.

Thank you for the rec on Stripe. I know the 3% fee is crazy and I havent taken the time to look for another solution.

My goal is to get mostly wire transfers. But I think you are right about the inevitability of getting something cheaper.

Thanks for the php tip for laravel, Ive heard of it and was part of my original plan. Oh boy, back into php :P

Reply on news.ycombinator.com