jbaxleyiii

Getting Started with React

React is quickly becoming the defacto javascript client library for building dyanmic and powerful applications. Its usage of a virtual dom, compliation support with react native, and really excellent lifecycle hooks, make it a fantastic addition to any application stack.

With any new framework, there is a learning curve associated with getting on board. React's can be steep but I think that is due more to lack of a clear tooling system than React itself. I've broken this guide into a few sections.

• What is React
• Hello World / Getting started
• Add on libraries
• Integrated stacks

jbaxleyiii

Rock Instances

As we continue to test and build with RockRMS, as well as run it in production with our church, we need a number of different testing envrionments. This document is the guide for where our instances live, who is responsible for them, and the purpose of them exsiting.

rock

This is our primary instance of Rock. It is the production server that our church builds off of and uses on a day to day basis. The web team is responsible for the uptime of the application, the solidity of the database, and the deployment of new code. IT is responsible for the uptime of the server and the backup of the database.

beta

jbaxleyiii

/* Sample injection for modal */
import React, { Component, PropTypes } from "react"
import { connect } from "react-redux"
import modalActions from "apollos/core/store/modal"


const SampleUIContainer = React.createClass({

  componentWillMount(){
    this.props.render(this.SampleUI, { name: "Ed" })

jbaxleyiii

Thoughts on high-level-reactivity from Meteor.

First and foremost, I want to say that the idea of reactive queries vs subscriptions is a great direction and one that greatly simplifies the syntax and process of getting data. After some experimentation with Falcor and Relay, it certainly seems like different approach is needed. After doing a fare amount of work both Redux and with SSR for Meteor, simplifying the data process is a must.

Current Proposal Thoughts

The client and server parts of the GraphQL system will need to collaborate to make this possible, but one of our goals is to make minimal changes to the current reference implementation of GraphQL so that developers can take advantage of current and future productivity tools for GraphQL.

I think this is critical to this project. I know its in the vein of this project but I've seen our team bounce around from abstraction libraries that obscure the underpinnings of what is going on and its very frustrating to break from spec. So all in all, I

jbaxleyiii

import { ApolloClient } from "apollo-client"
import { createNetworkInterface } from "apollo-client/lib/src/networkInterface"


// Middleware functions can perform the following tasks:
//
// -  Execute any code.
// -  Make changes to the request and request option objects.
// -  Call the next middleware function in the stack.
//

jbaxleyiii

import assign from "lodash.assign"

// style = {...style, this.props.style}
style = assign({}, style, this.props.style)

/*

style = {...style, ...{
  cursor: "inherit"
}}

jbaxleyiii

Here are some thoughts on a slight tweak to the query API and the mutation API.

Queries

Currently the API has a watchQuery method that is passed to the user to use in order to create queries. The build a dictionary of [key: string]: WatchQueryHandles that gets mapped to the props passed to the wrapped component. The adjustments below have the user creating a dictionary of [key: string]: WatchQueryOptions. The reason for doing this is two fold. 1st the connect component decides how to get data from the store. Behind the scenes it will be calling watchQuery but in the future if we wanted to add / make changes behind the scenes we could call different methods for different data (not sure if useful). The real benefit in my option is the WatchQueryOptions. Since the watchQuery handle isn't called when getting the dictionary anymore, we can get the dictionary in componentWillMount, use the WatchQueryOptions to see if we already have all of the data using getFromStore methods and if we do, the intia

jbaxleyiii

Remaining Roadmap for 2016 Systems Team

This document seeks to outline the rest of the calendar year of 2016 starting the first of June. Prior to June, the systems team has launched a new giving platform, NewSpring accounts, helped to launch Rock, and shipped a brand new internally built native app to iOS and Android.

Each project listed will be an epic with a description, an estimated timeline, estimated man power budget, and the business value the project brings. Each project will be tested (user and/or automated), documented, and has time allotted after shipping for bug fixes and needed immediate improvements. Doing this expands each projects traditional “development” time by a factor of three.

Embeddable workflows (signup.newspring.cc)

With the incredible power of Rock workflows out our hand, we want to allow for a more immersive and easy way for our users to take their next step. Through improvements to our GraphQL application, we can dynamically create workflows forms on the fly for our end u

jbaxleyiii

Included packages:

meteor-base mobile-experience mongo tracker es5-shim react-meteor-data check timbrandin:fetch accounts-password

jbaxleyiii

Currently the DX (Developer Experience) of working on apollos powered sites, apps, or the core framework is frustratingly difficult. This doc serves as a discussion point for improvements, particuarly through the idea of consolidation of apollos projects into a monolith.

Original Structure:

• junction
• apollos-rock (sync)
• apollos-core
• apollos-give
• my.newspring.cc (site repo)
• newspring-app (app repo)