Instructions:

Install a fresh react native project:
react-native init AwesomeProject

Install react-native-firebase:
npm i react-native-firebase --save

Run to the iOS installation guide
Add the google-services.plist
Add Firebase import to your AppDelegate.m, along with [FIRApp configure];

Run the Automatic Install
react-native link react-native-firebase
cd ios && pod update --verbose

Note: You need to use the ios/[YOUR APP NAME].xcworkspace instead of the ios/[YOUR APP NAME].xcproj file from now on.

Now we’re going to grab the Facebook SDK and add it to our xcworkspace file in XCode.

https://developers.facebook.com/docs/ios/getting-started/

Download the SDK and move it to ~/Documents/FacebookSDK

Follow the instructions to reference the framework files to the XCode project, add the Framework Search path to the Build settings, and add the necessary XML to to the Info.plist file in your RN’s ios directory.

After the Facebook SDK configuration is complete, try running
react-native run-ios

Updating XCode build paths

If the build fails, try updating the build path settings in XCode. Go to File > Workspace Settings > Advanced and select Custom > Relative to Workspace and add a build/ prefix to each path.

Quick tip: When running react-native run-ios with an external monitor, the Scaling will be off on the Simulator. You can hit Cmd + 1 to fix the scaling to 100%.

Another thing that threw me off initially was with the GoogleService-Info.plist file. I originally just copied this file to my ios directory. However, you should also drag this file to your XCode project root and create a reference, otherwise the build failed.

Dependencies

Once we have our initial run-ios running properly, we can start adding our React dependencies.

• Moment: Time/date handling library
• @shoutem/ui: Some nifty component styling shortcuts
• react-native-linear-gradient: Required by shoutem ui
• react native element: More UI stuff
• react native scrollable tab view: For horizontal navigation
• react-native-vector-icons: Lots of icons
• react-navigation: Currently the standard for react native navigation

npm install --save moment @shoutem/ui react-native-linear-gradient react-native-elements react-native-scrollable-tab-view react-native-vector-icons react-navigation

At this point it’s worth running react-native link to compile any package libraries to our XCode project.

React Native Facebook Login

I felt the Facebook SDK was inadequate (or just lacking documentation), so I’m additionally relying on the Facebook Login component to handle my login states.

##Navigation
This is a tricky topic, as the React Native community has been working out how navigation should be handled in a React Native app. React is, after all, a View layer to an application, so handling state in a component tree doesn’t readily translate into route handling.

One tip for React Navigation, is to use lazy loading in development for TabNavigator.

export const MainScreenNavigator = TabNavigator(
  tabRoutes,
  {
    lazy: true
  }
);

I ran into some rendering issues and an overload of requests on every refresh without enabling it.

App Icons

https://github.com/dwmkerr/app-icon

Conclusion

This is a part 1 of a series of tutorials for getting a React Native app up and running with Facebook login and Firebase backend.

Two rules I want to highlight today:

1. Only the variables from the last-matched RewriteCond are available as back-references. ¹⁾https://www.webmasterworld.com/forum92/5888.htm
2. Conditions only apply to the very next rule. You’ll need to repeat the condition in order for it to apply to another rule. ²⁾http://serverfault.com/questions/264076/rewrite-conditions-backreferences-passed-to-all-rules

This came in handy when I was testing out the following rules for a Drupal htaccess. Basically, I wanted all the admin pages to be routed to the .com English version of the site. If the editor tried logging into example.co.uk/uk/user, they would route to example.com/user. In the first example, I don’t have access to the HTTP_HOST backreference. It doesn’t matter in this case because i’m defining it in the rule. In the second and third rules, I’m repeating the condition so I can access the same back reference for two different rules.

    #keep admin pages on .com instance (uk only for now) (PROD)
    RewriteCond %{HTTP_HOST} ^(.*\.)?example.com$ [NC]
    RewriteCond %{REQUEST_URI} ^/(uk)/(user|admin)/?(.*)? [NC]
    RewriteRule ^(.*)$ https://www.example.com/%2/%3 [R=301,L,NC]

    #keep admin pages on .com instance (uk only for now) (DEV / STAGE)
    RewriteCond %{HTTP_HOST} ^(dev|stg).example.(co.uk|de|fr|nl)$ [NC]
    RewriteRule ^uk/user/?(.*)? https://%1example.com/user/$1 [R=301,L,NC]
    RewriteCond %{HTTP_HOST} ^(dev|stg).example.(co.uk|de|fr|nl)$ [NC]
    RewriteRule ^uk/admin/?(.*)? https://%1example.com/admin/$1 [R=301,L,NC]

I had been on and off with Backbone for some time but had finally come around to getting somewhat of an understanding of the basics of how Backbone is organized and how it can help with your JavaScript-robust applications. I’ve read numerous tutorials and hadn’t quite gotten the picture. They were either outdated, too bloated, or not enough. I’ll attempt at helping to clarify the basics in this tutorial and perhaps write more advanced topics later.

Some immediate things-to-consider from my approach sofar:

• I’m not using require.js, which I know a lot of front-enders depend on
• I’m relying on Yeoman’s Backbone Generator which saves an enormous amount of leg work for getting the structure of your application ready. If you haven’t tried Yeoman yet, give it a go. It’s super great for getting projects off the ground.
• Basically, what got me to this point was a combination of reading Addy Osmani’s Backbone tutorials and this tutorial which uses Yeoman to speed up the process.

Let’s dive in. First, we’ll look at our main.js file.

The init method immediately calls upon a view from our Todos colllection. In views/todos-view.js, our view defines most of the logic for interacting with our app, but we will frequently call on various methods defined in the Collection that it renders.

(function(){
    
    'use strict';
    
    window.backboneApp = {
        Models: {},
        Collections: {},
        Views: {},
        Routers: {},
        init: function () {
            console.log('Hello from Backbone!');
            new this.Views.TodosView({
                collection: new this.Collections.TodosCollection()
            });
        }
    };

    $(document).ready(function () {
        backboneApp.init();
    });
})();

For example, after completing the bare necessities of a Todo app, I wanted to add a Clean button that will clear all checked off items on the Todo Collection.

We’ll start by modifying our todos.ejs template and adding a ‘Clean’ button.

<form class="input-append">
<input id="new-todo" type="text" placeholder="What do you need to do today?" /> 
<input class="btn" type="submit" value="Submit" />
</form>

<form class="filter"><input id="clear-completed" class="btn" type="button" value="Clean" /></form>
<ul><!-- Where our To Do items will go --></ul>

We’ll now jump to our parent view, todos-view.js and add an event listener for our Clean button:

events: {
    'click #clear-completed': 'clearCompleted'
},

// Clear all completed todo items, destroying their models
clearCompleted: function() {
    _.invoke(this.collection.completed(), 'destroy');
    return false;
}

The clearCompleted method uses Underscore’s invoke method to get a list of the completed items and then use Backbone’s native destroy method to not only remove them from the view, but delete their models as well. The list of completed items is obtained from the collection’s completed method:

backboneApp.Collections.TodosCollection = Backbone.Collection.extend({
    
    completed: function() {
      return this.filter(function(todo){
        return todo.get('completed');
      });
    }

});

We’re using Backbone’s other native method, get, to obtain a list of models that have the completed attribute. Opening our todo-model.js file, we see that our model defaults to ‘false’. The ‘toggle’ method toggles this attribute. Backbone keeps track of these ‘states’ for each model.

(function(){
    
    'use strict';

    backboneApp.Models.TodoModel = Backbone.Model.extend({

        defaults: {
            title: '',
            completed: false
        },
        
        toggle: function() {
            this.save({
                completed: !this.get('completed')
            });
        }
    });

})();

I’ve joined the bandwagon on Digital Ocean’s cheap SSD VPS hosting options ($5/mo say what!) and have been very delighted to jump into a fresh Ubuntu shell with no issues. If you’re like me and haven’t been installing servers for years then you might find some of these tips helpful. I may add more tips later on so let me know if I can help with some general tips (not too fancy!?) for the future.

For starters, let’s start with everyone’s favorite: users and permissions. I always find it somewhat annoying when I add a user or settle on root and I have to continually type ‘sudo’ for simple things like writing to a file or adding a directory.

adduser myuser

This will create a /home/myuser directory. Now to grant all the sudo privileges to that user, it’s as easy as

usermod -aG sudo myuser

The -a makes sure that the sudo group is added and does not replace other groups assigned to the user.

Password Protect A Public Directory

Recently, I needed to create a staging site for a client but I wanted to keep the directory password protected and prevent it from being crawled by search engines.

You can password protect a public directory using the htpasswd command and .htaccess file.

You need to make sure a few things are in place.

First, make sure that your .htaccess is read by Apache by navigating to your site’s httpd.conf file (now referred to as site.conf in recent versions of Linux).

Navigate to /etc/apache2/sites-available.

cp 000-default.conf seojeek.conf // copy default settings
vi seojeek.conf

ServerName seojeek.com
ServerAlias www.seojeek.com
 
ServerAdmin me@seojeek.com
DocumentRoot /var/www/seojeek

<Directory "/var/www/seojeek">
Options Indexes FollowSymLinks MultiViews
AllowOverride ALL
Order allow,deny
allow from all
</Directory>

The AllowOverride ALL was added so that Apache would read and obey nested .htaccess files. Once I added .htaccess to the staging directory, I wanted to ensure that this directory was not visible to search engines (robots.txt) and password protected (.htpasswd file).

Robots.txt

We’ll start with the preventative measure of making sure search engines aren’t crawling my staging site.

At the site root, touch a robots.txt file and add the following:

disallow: /client_site_directory/*

Somewhere on the server, we’ll create a .htpasswd file that will store all of our username and encrypted passwords. We generate this with the htpasswd command. You may need to install apache utils first.

htpasswd .htpasswd username

Now, to password protect the directory, you’ll modify .htaccess:

AuthType Basic
AuthName "restricted area"
AuthUserFile /var/www/seojeek/client_site_directory/.htpasswd
require valid-user

Be sure to restart apache.

apachectl restart

Now, when you navigate to yoursite.com/client_site_directory, you’ll receive a login prompt!