Earlier quoted context omitted.
I've tried making a chat application using Ionic and it's been tough. The main issue is infinite scrolling by scrolling upward. The user scrolls to the top, we make a note of the current top comment, load the next set of results, add them to the page. At this point, the scrollbar is still at the top, so we need to manually scroll down to the previous top comment. It can be a little jumpy. It certainly isn't smooth li…
We're building a chat app in RN. Last I checked, the RN components do not support the functionality that you mention out of the box. We are using a fork of GiftedChat which has generally been a positive but not stellar experience ( https://github.com/FaridSafi/react-native-gifted-chat ). I understand includes some fairly clever (perhaps hacky?) and extensive changes on top of RN's components to mimic the interactions…
Ask HN: Companies who adopted React Native over a year ago, do you regret it?
111–120 of 149 posts
Re: Ask HN: Companies who adopted React Native over a year ago, do you regret it?
#112Re: Ask HN: Companies who adopted React Native over a year ago, do you regret it?
#113Earlier quoted context omitted.
As one of the designers of this app, I was skeptical initially if there would be restrictions on customizing common UI components, the smoothness of animations/interactions, usability, performance, etc. You definitely have to put in a bit of extra work (isn't that always the case with making things nice though), but you can get very nice results (and battery usage) with RN for sure on both Android and iOS. Personally…
One of the reasons I brought this up was a recent article about energy efficiency of programming languages.[1] JavaScript is ~2x less energy efficient than Java, so it will eat twice the battery. [1] https://sites.google.com/view/energy-efficiency-languages/re...
While the citation you provide is interesting, it doesn't inherently prove that in real-world usage, React Native apps consume twice the power of their native counterparts.
Re: Ask HN: Companies who adopted React Native over a year ago, do you regret it?
#114Earlier quoted context omitted.
So we've tried a lot of things to maximize code sharing. Our initial goal was to share non-visual code like reducers/action-creators/libs/utils etc… This was pretty interesting but it didn't give us the amount of sharing that we wanted. We were still building multiple versions of many things. The next approach we started on was using https://github.com/necolas/react-native-web . This was very exciting and very fun to…
Very cool. Are you driving the webview from React Native, or driving React Native from React/Redux code running in the webview? I imagine the latter would provide a seamless transition path for web-first shops, and you could probably do cool things with JSX syntax to make proxies for native components that feel like web components.
One of the things we swap to react-native was to do a barcode scanner. With WebRTC support in iOS11 we may not even need to do that for long.
Re: Ask HN: Companies who adopted React Native over a year ago, do you regret it?
#115Earlier quoted context omitted.
If you have to ask questions like this, you haven’t been working in the industry long enough.
OK. Let's say that's completely true. Is snarkily telling someone they're not good enough helpful? Seems like a moment where you could share what you know (as someone, presumably, has been in the industry long enough) and help someone. (FWIW it sounds like a decent question to me: but then again undoubtedly I have not been in the industry long enough!)
The answer is: it’s in our nature to make simple things difficult.
It shows more maturity if you just accept people do stupid things without trying to pry a rationale out of them IMO.
Re: Ask HN: Companies who adopted React Native over a year ago, do you regret it?
#116Earlier quoted context omitted.
Haven't been in the industry long enough to do what? Ask questions? It appears you have been working in the industry too long to answer them, which is much worse.
> Haven't been in the industry long enough to do what? Ask questions? To be jaded. It's merely a jab at the way we tend to overcomplicate solutions to simple problems. I think.
Re: Ask HN: Companies who adopted React Native over a year ago, do you regret it?
#117Absolutely not. We went all in on it. We even developed our own open source framework based on it called Gluestick. It's original purpose was to make it automatically isomporphic by running the same code in the browser as on the servers, using node. We also built a component/style library that allows us to make responsive designs into web and mobile apps quickly and easily. Gluestick also allows easy creation of nati…
Re: Ask HN: Companies who adopted React Native over a year ago, do you regret it?
#118Absolutely not. We went all in on it. We even developed our own open source framework based on it called Gluestick. It's original purpose was to make it automatically isomporphic by running the same code in the browser as on the servers, using node. We also built a component/style library that allows us to make responsive designs into web and mobile apps quickly and easily. Gluestick also allows easy creation of nati…
How are you doing code sharing between web views and native? Is this an (open-source??) high-level component library that conditionally compiles to either 's or 's? Or did you actually find a way to render ReactDOM components within React Native inside some sort of controlled web view? The latter IMO would be a holy grail for companies trying to transition large ReactDOM codebases to native apps gradually.
Currently I use this functionality exclusively for platform specific branching, without any platform-specific conditional logic in my codebase whatsoever. So to give a really trivial example, you can have something like this:
In App.js (shared as-is across platforms):
import * as element from './element'
export default () => (
Hello world!
)
In element.js (for web components): export const View = 'div'
export const Text = 'span'
In element.android.js (for android specific components): import ReactNative from 'react-native'
export const View = ReactNative.View
export const Text = ReactNative.Text
This way once you build up a set of reusable lower-level cross platform components that share the same APIs, you can compose these components together without any platform specific branching, since the differences between platforms will be abstracted away by these lower level components, which will automatically get loaded by the React Native packager for the appropriate platform.In practice, a lot of elements don't map one-to-one between web and React Native, and will require a lot more shimming to get at a reasonably close API (forms, inputs, and lists have been especially painful so far), but React's component model gives you all the tools you need to handle and smooth over those mismatches. This approach works great for utility functions that need to provide platform dependent functionality as well, so it's not just for elements.
Disclaimer: My project is still in a super early stage right now, so I'm not sure how well this approach can scale, but so far I'm enjoying the experience a lot more than I thought I would thanks to this approach, due to the lack of need for platform-specific branching logic in my code.
Re: Ask HN: Companies who adopted React Native over a year ago, do you regret it?
#119We have a 15-person engineering team and converted our mobile app to React Native at the beginning of this year. We do not regret it. Our pace of delivery is much faster with React Native than what we were able to achieve building natively. Our app has over 100 screens, and only needing to implement features once to have them on both platforms is nice. The feedback loop when making code changes is much faster, especi…
How do you manage 100+ screens? I started building a react native app but decided against it because switching activities seemed to be very hacky compared to native development. Seemed like it'd really get out of hand with 10+ screens. Wix's "React Native Navigation" was too opinionated / inflexible.
It's actually quite easy
Re: Ask HN: Companies who adopted React Native over a year ago, do you regret it?
#120Earlier quoted context omitted.
> One question I have is why did you prefer Typescript over flow? I don't want to start a holy war on this, as it's generally accepted that Flow's type system and inference is superior. I believe TypeScript is a generally better solution despite this, for other reasons. This is just the list I can come up with offhand: Upsides for TypeScript: * bigger community * more definitions (This cannot be overstated; the gap i…
Thanks for this. I'm still relatively new to the Javascript world (mainly native developer) and I've only just started using flow. Could you tell me a bit more about the following points: * more definitions (This cannot be overstated; the gap is wide) and * great compiler I'd love to hear more about this and or read some good articles comparing flow to typescript.
flow can be added to an existing project
i feel that almost everyone underestimates how important this is