Been a little slow to announce updates, so I’ll try to be better. V0.29.0 is a pretty big update from the React Native team. A ton of iOS and Android fixes/updates, here are some of the breaking updates:
- Kill NavigationReducers (3a8b50a) – @hedgerwang
- NavigationExperimental – Clean up NavigationStateUtils (67002e8) – @hedgerwang
- Remove the logic that lets NavigationStateUtils accept empty value as input and return a new state.
- Remove the method
- NavigationExperimental – Remove prop
onNavigate (fb0007d) – @hedgerwang
- NavigationExperimental – Define the generic
render prop for NavigationTransitioner to render scenes (3a62314) – @hedgerwang
Check out the full release notes here.
It’s been a little quiet lately, so this little gem caught my attention. Looks like we have another “major” (yes, I know it’s a minor version bump but since we’re not at v1.0 yet, I consider this a major update) release from the React Native team. React Native v0.25.1 looks like a nice bump in features for both Android and iOS. Here are the general updates:
- Add key to footer wrapper in WindowedListView – 58db9f3
- Add support for missing XHR response types – fcc89e9
- Add a way to prefetch remote images to cache with Image.prefetch – f7bcb3e
- Add transform-es2015-function-name to the react-native babel preset – 855c0cc
- Add instructions to reload simulator for non-QWERTY keyboards – c417c2e
- Add support for ontimeout and onerror handler when using XMLHttpRequest for Android and iOS –d09cd62
- Add null check before accessing the refresh control ref – eac617d
- Fix HMR on Windows – c61100d
- Fix up PanResponder example – 05a852a
- Fix an issue when the title in NavigationExperimentalHeader would block touches for the left component – 86d5c52
- Fixed images required from node_modules – d0566d8
- Fix an edge case in hot module reloading – 41576ea
- Fix warnings in UIExplorer example pages – 528cf68
- Fix perf tab missing key warnings – b7a3272
- Fix swiping in navigator too quickly causes the gesture to be lost – ca2fb70
- Fix border radius / background propagation issues in TicTacToe example – 97f60ad
- Fix race conditions in Portal when simultaneously closing/opening – 7354ff3
- Fix ImageEditingManager when no external cache – fffcb9c
- Fix RefreshControl refreshing state – 93b39b7
I hate to say that I am woefully behind in terms of updating my React Native projects. I’m somewhere in the v0.18 range. I have been doing more React web lately. As much as I enjoy doing mobile development, there is something infinitely more satisfying being able to write code and refresh a browser than having to update an emulator (even if it’s as easy as CMD+R) and don’t forget that it’s so much easier to send a link to a web-based proof of concept than getting someone to install an app on their phone. Anyways, that’s just me ranting about how much I prefer being a web dev over a mobile dev. Back to the topic at hand, go check out React Native v0.25.1 and make something awesome.
So I’m starting a new project and decided to use my React Webpack boilerplate as a starting point. The first thing I realized was that my node modules were really behind. So I did what every JS developer does and upgraded everything – and then everything broke (which is exactly what happens to everyone). Anyways, the big updates include upgrading React (didn’t make the jump to v15.0 yet) to v0.14.8, upgraded Redux to v3.3, upgraded React Router to v2.0, switched from redux-simple-router to react-router-redux and other smaller upgrades like upgrading lodash to v4.0 and upgrading babel to the latest versions. Most things worked, some of the Redux and React Router syntax had changed and required updates and server side/universal rendering broke and had to be fixed. But overall, got it to work and also started converting components to ES6 classes. So lots of improvements and even started working on my new project – more on that to come. Anyways, as we know that JS changes on a weekly basis, I’m trying to keep up, so here’s the latest and greatest.
Microsoft announced support for React Native on the Universal Windows Platform at Facebook’s F8 2016. And while this is interesting, it’s not very applicable to me at this point. I just checked and currently this is just a fork and I don’t know if/when it will be merged back into master. This isn’t too surprising considering the recent announcement that Visual Studio would support React Native. Back when I was doing .NET development, Visual Studio was a nice IDE (but I’m much happier on a Mac over Windows). There were also some interesting comments regarding how React is becoming the next Qt that will finally deliver on the promise to provide cross-platform support. Well, technically, it will give you a solution that let’s you “learn once, write everywhere” but not the holy grail of “write once, run everywhere”. In any case, I like seeing React continue to grow and evolve – I not only get to use it in more places (mobile, desktop, web, maybe embedded and/or wearables one day), I also get to talk to more people about it because everyone is using it (but in different ways). So I will continue to support Facebook’s world domination and the continued proliferation of React.
So the day has finally come and React v15.0 is being released. I talked about this before when the announcement to go from v0.14 to v15.0 was made. It’s been less than 2 months since the announcement was made and here we are. And this isn’t just a version bump announcement, there’s a bunch of updates – unfortunately, some breaking. Here’s the “warning” on upgrading and what to consider:
As usual with major releases, React 15 will remove support for some of the patterns deprecated nine months ago in React 0.14. We know changes can be painful (the Facebook codebase has over 20,000 React components, and that’s not even counting React Native), so we always try to make changes gradually in order to minimize the pain.
If your code is free of warnings when running under React 0.14, upgrading should be easy. The bulk of changes in this release are actually behind the scenes, impacting the way that React interacts with the DOM. The other substantial change is that React now supports the full range of SVG elements and attributes. Beyond that we have a large number of incremental improvements and additional warnings aimed to aid developers. We’ve also laid some groundwork in the core to bring you some new capabilities in future releases.
The full announcement with all the updates, fixes and breaking changes can be found here. I just checked and it appears that v15.0 is now available on NPM. I just started a new project last night, so I’m torn if I should make the jump to v15.0 or if I should continue to use v0.14 and let v15.0 stabilize. I think while I’m trying to get the barebones working, I’ll stick to v0.14 and I’ll upgrade to v15.0 before I release the app. Good luck upgrading everyone.
A new version of React Native is now available. New features include:
- Add ability to silence packager logs to stdout – d5445d5
- Add the possibility to
console.error/redbox on promise rejections – f87b673
- Add more performance logs and improve Systrace support – f6853b8
- Initial implementation of the Navigator with NavigationExperimental. – fa5783e
<Incremental> for incremental rendering – f21da3a
- Add ability to specify custom left, right components, and title component in
NavigationHeader. Style the
NavigationHeader according to the Platform – 720c76f (Breaking)
I am pretty impressed by the frequency of releases – v0.22.0 was released 17 days ago. So in a little over 2 weeks, 91 contributors made/reviewed/tested 234 commits. Also really happy to see a number of new features and fixes for both Android and iOS – both platforms are continuing to get love and evolve. While I haven’t spent as much time working with RN lately, I know that when I go back to working with RN, there’s going to be a lot of improvements for iOS and Android will be stable and have a lot of examples and support from the community.
So I’m not going to rehash the entire controversy that triggered the un-publishing of NPM modules that ultimately broke everyone’s build. Everyone has an opinion of whether is was right or wrong, but the only thing everyone does agree on is that this brought light to a giant flaw with the NPM ecosystem. I’m not going to comment on NPM’s original decision that sparked the controversy but I think their changes in regards to un-publishing modules is pretty logical (it was basically what I came up with in my head) – so the basics rules are now:
- If the version is less than 24 hours old, you can unpublish it. The package will be completely removed from the registry. No new packages can be published using the same name and version.
- If the version is older than 24 hours, then the unpublish will fail, with a message to contact email@example.com.
- If you contact support, they will check to see if removing that version of your package would break any other installs. If so, we will not remove it. You’ll either have to transfer ownership of the package or reach out to the owners of dependent packages to change their dependency.
- If every version of a package is removed, it will be replaced with a security placeholder package, so that the formerly used name will not be susceptible to malicious squatting.
- If another member of the community wishes to publish a package with the same name as a security placeholder, they’ll need to contact
firstname.lastname@example.org. npm will determine whether to grant this request. (Generally, we will.)
So there was a lot of criticism about the changes saying that it doesn’t address the original problem that sparked everything. I’ll give my commentary that while it doesn’t address the pre-cursor to the un-publishing of the modules, it does solve and prevent users from breaking people’s builds so I call that a win for all of us. On a completely separate topic is the question/problem of who owns a package and ultimately, it’s NPM and I will respect their rules because I ultimately benefit form them as an organization and I feel they contribute and make things better overall. So while I was annoyed with the broken builds and could assign blame to a number of parties (well, like 2) – I feel like NPM has made changes to help protect this from happening again so I ultimately am going to move on and focus on more important things (and I think everyone else should too).
So I wasn’t even aware that this existed, but after reading about it, I’m surprised I didn’t come across this sooner. I’ve been using Fabric and I even tried using the built-in Twitter login, but as we all know, no one really uses Twitter to login to apps. At my last company when we introduced social-login, we saw basically almost a 50/50 split between FB and Google and just a couple percent for Twitter. So I’m excited to try out FBSDK to integrate FB login in my next app. Over time, I’ve moved away from implementing my own login system and if possible, just leverage OAuth through a trusted source like FB or Google. And, it was great to hear that the new version of FBSDK adds support for Android. Oh, and the part that I was surprised to see is that this is provided by the Facebook team, also a little surprised that this hasn’t received more attention. I would have thought this would be sold side-by-side with React Native so that every app has built-in FB integration. I’ll post my experience next time.
From the README directly:
Looks like the Google App Engine team has just announced support for Node.js. I’m glad to see GAE expanding their offering. I tried GAE for a PHP app back when they started supporting PHP and it worked pretty well. The pricing wasn’t great for side-projects, but I’ve heard that has gotten better lately. And while I wouldn’t launch a mission-critical Node app on GAE right now, it’s nice to know their are other options besides AWS. But I will also caution people to GAE, there was a lot of mixed feedback from the crowd over at Hacker News – some raving about GAE and other having horrible experiences. As always, YMMV, so make sure to do your research and test out the different platforms before you go all-in.
And since I mentioned side projects, I’ll definitely make a plug for Digital Ocean and Dokku. For $5 you can create a droplet with 512 MB, 20 GB SSD and 1000 GB transfer which is more than enough for multiple side projects. Since DO supports Dokku images, it’s super easy to spin up a droplet and start deploying apps to your droplet. If you’ve used Heroku, it’s that easy to deploy to Dokku.
This looks like a really nice UI kit to include search if you’re using React and already have Elasticsearch. Lots of useful components that you can use (or not use) such as Toggle, Select, ItemList, CheckboxItemList, ItemHistogramList, Tabs and TagCloud. The full announcement can be found here. I’m not exactly clear on how customizable the UI is as far as custom styling but it’s a pretty nice start. I also like how you can extend the results list view to basically show whatever you want. And the RangerFilter component is also pretty nice. I’m curious how it handles more than a couple hundred results. I’ll definitely play around with this and put up a quick demo when I have time. If you can’t wait and want to give it a try yourself, go check out the documentation.