In this article, we’ll take a look at some simple guidelines and practical advice which can be useful for remote teams, or teams who have remote workers, to enable both to communicate more effectively. By the end of the article, I hope that you will be encouraged to consider writing a shared team document that describes your team’s communication principles — or at least to be curious about how your team currently communicates and whether there are improvements you could make. Let’s dive in!
If you’re using React’s useState hooks in your frontend application, you may not know that the setter function can also accept a function as an argument. This can be used to avoid unnecessary re-renders when combined with useCallback.
The JS ecosystem moves forward at a break-neck pace. New paradigms, frameworks, and tools are released seemingly every day. React Hooks are a recent example of this, with many software houses dropping tools in a race to rewrite their codebase to use the new techniques. But what do you do if you’re in a small team, managing a non-trivial sized codebase, with limited time to invest in staying on the bleeding edge?
As a junior developer, I was often fraught with insecurity and imposter syndrome with regards to my technical ability, and actually postponed the beginning of my career by at least a year due to these feelings.
Over the years these feelings have diminished somewhat, although not completely. Whilst not all of these points are related to confidence, if I had a time machine, I’d go back in time and tell myself these things.
In this article we’re going to learn how to write a modern GraphQL app that utilises some of the awesome new APIs recently announced by the Apollo team. Rather than starting from scratch, we’re going to build upon and refactor our counter app example from our previous exploration of apollo-link-state. To remind yourself of where we got to last time, have a play with this Snack.
Query Components Query components are one of the brand-spanking-new features of Apollo 2.
In this article we’re going to build a simple counter app to learn the basics of apollo-link-state and how we might use it to manage the local state of our apps. GraphQL is a fantastic and modern approach for dealing with data in your apps. Before you continue, it’s worth making sure you have a basic competency with GraphQL, Apollo and also React Native.
What is apollo-link-state? apollo-link-state is a middleware for the Apollo stack that allows us harness the power of GraphQL to manage our local app state.
In this day and age computer security has never been more important. Open source software powers much of the world’s computing infrastructure and as such, we are dependent on the integrity of this software from a security point of view. Code is merged into open source repositories in a structural and intentional manner. However, it’s theoretically possible for a user to masquerade as another simply by changing their Git username and name.
It’s a common scenario to display images that are hosted on a remote server. There’s great built-in support for this with React Native. However, if you start loading the image at the instant you need to display it to the user, you may end up displaying some loading progress or perhaps the user won’t even stick around long enough to see the image.
While working on an optimisation task, I came across some interesting methods for accessing the native image cache.
It’d been quite a while since I last worked on my React Native plugin for indexing your app’s content. During this time, react-native-spotlight-search had become quite out of date and no longer worked with modern versions of React Native.
So, thanks to some help from fellow contributors I’ve recently published a new version that addresses all of these issues and generally tidies things up 🎉
What’s New Support for modern React Native versions Fix deprecation warnings Rebuilt the example project to use RN 0.
I’ve recently been involved with a mobile app project that required frequent public releases from a master branch that contained a mixture of complete, stable features and other features that are still under heavy development. The latter features are in no shape to be shipped to the public — so how do you keep these out of the public release but readily accessible for development? One potential solution, and one that my younger naive self might have attempted, would be to maintain a feature branch for each feature that was in active development, with a view to keeping these branches un-merged until the entire feature is complete and ready to use.