Redux may not be fashionable right now, but when I need to show React off to new developers, I usually start by showing them Redux dev tools (“I can see the state of my app while it’s running! Check this out, time travel debugging! Cool, huh?”)
Redux makes synchronous state updates explicit and reasonable, and makes visible the contract between React and the application: UI is a function of state, and it’s for this reason I’ll continue to use it.
Things have improved in the React Native routing ecosystem— there are no longer several “official” navigators competing with community efforts — but the currently popular libraries still seem unwieldy, overly prescriptive and not performant enough.
Ti.App.Properties can be read by React Native.
I recently worked on a React Native rewrite of an Appcelerator Titanium app. To provide a seamless update for our users, we needed to maintain app properties —in our case, authentication tokens — after they upgraded to the shiny new React Native build.
The Titanium docs state that properties are in iOS are held in
NSUserDefaults plist files, and Android properties are in a
For Android then, getting your Titanium properties is straightforward:
Firebase server events + Firebase authentication = Redux-like action handling for fun and profit
I was recently asked about patterns I use when using Firebase with React and NodeJS (no, I really was!)
If you’re reading this, you probably know Redux and the elegance of its unidirectional data flow. Given that both a Redux store and the Firebase database are essentially just a monolithic object, I’ve used (okay, stole) the conceptual ideas of Redux to set up a secure and predictable way of updating my global Firebase dataset.
in which I talk about the FERN stack: Firebase — Express.js — React — Node.js
(On stacks… webbish types are fond of referring to how they create web things using an acronym of the technologies involved; so a Linux machine running the Apache webserver, using a MySQL database running the PHP language would be a LAMP stack)
Hey everybody, immediately bin all your MEAN, LEMP, LAMP, WAMP and WIMP stacks!
Give me an F….
Just a database, right? And some other stuff that Google have rebranded like their cloud storage and messaging services?
Firebase’s services, excellent on their own…
I love BEM, the HTML/CSS/JS class naming methodology. You may too. Even if you don’t use it, you may be aware of it. It has 4 constructs:
Except that is not the whole story. There is another BEM, with a similar, but different, syntax.
This is the alternative syntax. I call it Classic BEM. It has 6 constructs:
Both syntaxes say names-must-be-hyphenated.
Both syntaxes say that there’s a double underscore between blocks and elements.
They part ways on modifiers. I call the 4 construct syntax Western BEM, and it uses…
My organisation had a directory structure for projects like:
Which had been fine with our grunt toolchain for SCSS, JS etc.
When I added JSX and react via browserify I found I encountered an “Error running grunt-browserify”
>> Error: Cannot find module ‘react’ from ‘/directory/of/source/jsx’
There may be a simple way of telling grunt-browserify (or similar, I had the same errors when investigating alternatives) the location of the node_modules/ for modules, presets and plugins, but until I find out what it is, I have reorganised to:
Hello! I’m a software developer based in the UK. I write niche articles about Firebase, React, React Native and other development bits and bobs