101–110 of 259 posts
I would though love react jsx syntax for building native views in swift/Kotilin.
Earlier quoted context omitted.
I'm excited about the proposed changes and think they are a step in the right direction, but I also worry that they will add more fuel to the fire that react-native as a platform is a constant moving target. You obviously have much more insight into what the re-architecture will entail than I do but I've heard a lot of worry around that post with regards to backwards compatibility of third party libraries and in-hous…
To provide some extra context on this: at FB, we can't ship any RN update (or really, any RN commit ) without updating our own apps for it. No product teams at FB are going to agree to rewrite their code just because an infrastructure team came up with a new way to do something. The reason updates are easier at FB mostly has to do with atomicity of commits. Because FB uses RN from master (and in practice all code liv…
My current company casts a weary eye at third party software so the import process is slow and involved. This means we only take major versions, and usually not very quickly. When those versions then introduce regressions in our own products and in dependent libraries it only serves to strengthen the voices calling to ditch the external solution entirely. It'd be a different story if a major version seemed to be of consistent quality to squat on for a while, but each new version brings its own challenges.
To be clear this is all involved in life as a dev in a large software company. For my own personal use I'd rather see RN move as fast as possible. I'm fighting the good fight to keep up (and increase) adoption at work so I just hope that FB and the RN team keeps these things in mind.
Thanks for the additional insight here.
Very good write-up, thanks for posting. Some of the frustrations definitely hit home. I think for small teams and indies React Native is an awesome piece of technology that can enable them to target both platforms where it would be nearly impossible otherwise. I can understand how orchestrating the work of a huge team could introduce new issues though. It would be interesting to know why some of the infra layers that…
Yet another company discovers what many of us did ages ago with multi-platform frameworks. Additional layers not supported by platform owners, mean extra debugging efforts tracking down which layer is responsible, catching up with native SDK features, need to be an expert at both layers, lack of integration with native debugging tools... But business always wants the Ferrari solution at the cost of a Fiat panda.
While I don't disagree with your premise, "need to be an expert at both layers" is absolutely still true if you build your app natively for each platform (more so, even). At least with a common platform, if nothing else, you can share quite a bit of code, and that alone might make it worth the extra layers.
Earlier quoted context omitted.
I never understood the obsession with native navigation libaries. I built a bunch of apps with JS navs and nobody ever complained...
"Built-in" and "native" don't mean the same thing last time I checked.
E.g. react router on web has gone through many versions and there are several community libraries for doing web navigation and how you want to track that application state.
Very good write-up, thanks for posting. Some of the frustrations definitely hit home. I think for small teams and indies React Native is an awesome piece of technology that can enable them to target both platforms where it would be nearly impossible otherwise. I can understand how orchestrating the work of a huge team could introduce new issues though. It would be interesting to know why some of the infra layers that…
What's wrong with hand coding flexbox styles?
Earlier quoted context omitted.
You can disable cache while dev tools are open in chrome but its not the default.
And, annoyingly, if you check the disable box any time you close the dev tools it resets to unchecked. If you reopen dev tools it still remains unchecked.
Yet another company discovers what many of us did ages ago with multi-platform frameworks. Additional layers not supported by platform owners, mean extra debugging efforts tracking down which layer is responsible, catching up with native SDK features, need to be an expert at both layers, lack of integration with native debugging tools... But business always wants the Ferrari solution at the cost of a Fiat panda.
Earlier quoted context omitted.
The common thread I see is that mixing native and react-native is hard. Doing so while working across organizations that may or may not use react-native is doubly so. Sometimes this boils down to the technology, knowledge, and the engineering systems needed to support both but I've also found native developers tend to strongly dislike react-native and lobby against whenever they can. For me, I'm using it to successfu…
I invested a lot into a full React webapp - it would be great to share some of that code with mobile apps. I have an iOS background but was intending to make a RN app so that I could share the bulk of the React webapp code and get Android support as well. I have separation of container components and presentational SFCs so I’m thinking I could easily re-implement UI layers in RN if I wanted to without sacrificing the…
For sharing presentation, I'm hopeful for solutions like react-native-web.