amcvitty

Password Autofill on a React Native Expo app

Developing an app to accompany our website, worried that we would lose people in the transition if they couldn't remember their password, we were looking to make our app do Password AutoFill, a feature in iOS.

A talk from WWDC introducing the feature: https://developer.apple.com/videos/play/wwdc2017/206/

It works well, but there were a few bumps in the road making it work for React Native on Expo, so here are some notes to help out.

Apple's docs are here: https://developer.apple.com/documentation/security/password_autofill and they say something like this:

ivanalejandro0

-- Thanks to:
-- https://coolaj86.com/articles/how-to-control-os-x-system-volume-with-applescript/
-- https://robservatory.com/silently-mute-the-mic-input-via-applescript/
-- https://macscripter.net/viewtopic.php?id=16588
--
-- For integration with the system see: http://eddmann.com/posts/creating-a-mac-microphone-mute-keyboard-shortcut/
--
-- In order to keep the `storedInputLevel` value you need to use it compiled:
-- $ osacompile -o toggle-mic.scpt toggle-mic.applescript
-- And then run:

ncochard

When you create a npm package, remember it might be used in a browser or a server, or even a command line utility… For each package you create, please pay attention at what it will be used for:

1. Is it going to be used as a dependency to a nodejs application that is not bundled? (e.g. command line utilities)
2. Is it going to be used as a dependency to a nodejs application that is bundled? (e.g. AWS Lambdas)
3. Is it going to be used as a dependency to a browser application (always bundled)?.

• In cases 2) and 3) you want to allow for tree shaking.
• In cases 1) and 2) you want to benefit from the "ES6"/"ES next" features supported natively by nodejs.
• In case 3) you also want to benefit from the native support of "ES6" from your browser.

LawJolla

import React from "react";
import { renderToString } from "react-dom/server";
import ApolloClient, { createNetworkInterface } from "apollo-client";
import { ApolloProvider, getDataFromTree } from "react-apollo";
import { ServerStyleSheet, StyleSheetManager } from "styled-components";

// function to generate hydrated state for client side Apollo
function makeApolloState(ssrClient) {
  const state = { apollo: ssrClient.getInitialState() }
  // appends apollo state to the global client window object

przbadu

STEP 2: setup docker to run react app (dev and production) configuration: https://gist.github.com/przbadu/929fc2b0d5d4cd78a5efe76d37f891b6

Setup Docker for React development

Because we are using Docker, we are not going to install node, npm, create-react-app in our development machine, not even for generating create-react-app scaffold.

For this purpose I am using 2-step docker configuration:

• In first step, we will create a simple docker container, that does only one thing, install create-react-app

blankg

/**
 * Created by Guy Blank on 3/9/17.
 *
 *  This is a sample provides an API to send & receive messages to and from the React-Native WebView (using postMessage/onMessage WebView API).
 *  A sample project that uses the bridge is available here https://github.com/blankg/rn-webview-bridge-sample
 *
 *  webViewBridge.send('functionToInvoke', {mydata: 'test'}, function(){console.log('success')},function(){console.log('error')});
 *
 *  The API is designed to be similar to the Cordova exec API so migration to it should be almost seamless.
 *  The API also provides solution to a React-Native WebView bug in iOS which causes sending consecutive postMessage calls to override each other.

jayphelps

{
  "scripts": {
    "build": "npm run build:es2015 && npm run build:esm && npm run build:cjs && npm run build:umd && npm run build:umd:min",
    "build:es2015": "tsc --module es2015 --target es2015 --outDir dist/es2015",
    "build:esm": "tsc --module es2015 --target es5 --outDir dist/esm",
    "build:cjs": "tsc --module commonjs --target es5 --outDir dist/cjs",
    "build:umd": "rollup dist/esm/index.js --format umd --name YourLibrary --sourceMap --output dist/umd/yourlibrary.js",
    "build:umd:min": "cd dist/umd && uglifyjs --compress --mangle --source-map --screw-ie8 --comments --o yourlibrary.min.js -- yourlibrary.js && gzip yourlibrary.min.js -c > yourlibrary.min.js.gz",
  }
}

jonchurch

var crypto = require('crypto');
var bodyParser = require('body-parser');
var debug = require('debug')('botkit:verify_xhub_fb');

module.exports = function(webserver, controller) {

  if (controller.config.validate_requests === true) {
      // Load verify middleware just for post route on our receive webhook, and catch any errors it might throw to prevent the request from being parsed further.
      webserver.post('/facebook/receive', bodyParser.json({verify: verifyRequest}));

CMCDragonkai

#!/usr/bin/env bash

[[ $- == *i* ]] && echo "This Bash Shell is Interactive Shell" || echo "This Bash Shell is Not a Interactive Shell"

shopt -q login_shell && echo "This Bash Shell is a Login Shell" || echo "This Bash Shell is Not a Login Shell"

chantastic

Hi Nicholas,

I saw you tweet about JSX yesterday. It seemed like the discussion devolved pretty quickly but I wanted to share our experience over the last year. I understand your concerns. I've made similar remarks about JSX. When we started using it Planning Center, I led the charge to write React without it. I don't imagine I'd have much to say that you haven't considered but, if it's helpful, here's a pattern that changed my opinion:

The idea that "React is the V in MVC" is disingenuous. It's a good pitch but, for many of us, it feels like in invitation to repeat our history of coupled views. In practice, React is the V and the C. Dan Abramov describes the division as Smart and Dumb Components. At our office, we call them stateless and container components (view-controllers if we're Flux). The idea is pretty simple: components can't