The word colocation gets thrown around a lot these days.

*Styles* in my mind being the biggest example There seems to be a near constant conversation revolving around *colocating* styles with components, the argument often being that styles are **part** of the component and without them it would not be what it is. Putting the two together allows one to reason in a single place about what will appear on the page.

I won’t get into that here because I wish to spend most of my time *not* arguing about styles on twitter.

What I’ll talk about instead is React hooks, I believe they have introduced a place where we have an astonishing chance for colocation in data fetching and data flow in general.

I didn’t randomly choose to put bread and cheese emojis in the header image because those just so happened to be the two things currently on my mind, I see them as a great example of things that are commonly *colocated* in this real world everyone keeps telling me about (but I don’t get MTV I respond to rapturous laughter).

As hooks gain more and more popularity, specifically **useReducer** we often begin to see it paired with **useEffect** in many different sorts of ad hoc ways in fetching data. Something like this contrived example below:

This code, barring mistakes I almost definitely made, should work, but the thought of slogging through this every time I’m doing something like loading an avatar is a nightmare. But I still love the **useReducer** pattern so whatttttt am I to do.

I believe **ReasonReact** has already solved for this with the reducerComponent

**ReasonReact** provides the functions *Update*, *UpdateWithSideEffect*, *SideEffect*, and *NoUpdate* which are than used to wrap the value returned from the reducer allowing not so much the colocating of side effects with the reducer (which we still want to keep pure) but the colocation of the **INTENT** of side effects that will follow.

We can take this idea and bring it over to the world of React hooks to give us a somewhat similar experience, remove excessive code like that seen above, and provide a common pattern for teams to execute actions that lead to side effects. Hopefully causing easier understanding of the code, easier to review pull requests, and the actual important reason, less bugs reaching the end user.

Here’s what the above code might look like in that world.

We can take this idea and bring it over to the world of React hooks to give us a somewhat similar experience, remove code like that seen above, and provide a common pattern for teams to execute actions that lead to side effects leading to easier understanding of the code and easier to review pull requests.

Here’s what the above might look like in that world.

We’re now able to colocate the fetching of the avatar with our declaration of intent to fetch the avatar, allowing us to follow in one section of code exactly what is happening.

I believe **ReasonReact** got this **super duper extremely correct** and am excited to use this pattern with React hooks as I develop new features.

You can see a library implementing this pattern here and to be honest it’s not all that difficult to do this or something similar on your own.

If you’re interested in hearing more on the topic and are the SF Bay Area I’ll be speaking on the topic at the July React Meetup

Looking forward to hearing what everyone thinks!

Colocating Side Effects With Actions Using useReducer was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

Previously (and mostly still) we make opaque calls to a backend REST API AND we kind of know what we’re getting back because we read some hopefully up to date swagger documentation or we talked to the backend engineer who sits next to us or however we got into this inner circle of API knowledge.

This doesn’t account for a lot of things though. Someone else may take over development of the application, all they see is a request, maybe that request returns a ton of information that isn’t used and that person wonders why. They’ll crawl through some code and eventually figure out how the API works and go about their day because that’s a not all that difficult thing to do.

The paradigm shift that GraphQL brings — and I’m sure this has been said in hundreds if not thousands of previous blog posts — is that that opaqueness is removed, what you see is what you get.

Here we can see we’re saying i want the hero, his friends, and his friends names. We know our frontends will get this data, or at the very least an object in this shape with some null fields.

For a long time I’ve thought about where the value in GraphQL lies, and there is no doubt in my mind that the type system and guarantees it provides are immensely powerful and endlessly helpful for API development and development on the front end, you know not only the shape but type of data you are getting.

Are there compromises we can make though? We have some APIs that are years old, some companies that are unwilling to invest in GraphQL as a technology, and a million other reasons we may not have a GraphQL server we can hit.

Should this rob us of our ability to have an expressive frontend development experience in which we can clearly see our components data needs colocated with the component itself? I don’t think so.

This is a problem that has kept me up at night for a very long time, and while this project is in its infancy I felt it would be better to share early and get feedback so maybe this silly idea in my head can become a real option as a middle ground between going all in on GraphQL and having opaque front end data handling. My goal is to use the expressive front end of the GraphQL query language while hitting any arbitrary backend, to have a new developer look at a component and say hey this is the data that’s supposed to come here and it’s not, now I can ask an informed question. I think I’ve made some really great strides in making this a real possibility.

If you look at the above code it really doesn’t look all that different from an Apollo HOC query. the difference is here there is no backing GraphQL server, the query data is being translated into calls to arbitrary API endpoints using the GraphQL parser on the string and then traversing the AST in order to gather the relevant information to make the calls. The paradigm here essentially calls for the top level items (person, post, todos) to be routes available on the apiPrefix (or root of your server if apiPrefix is not provided)

From there we gather up relevant route parameters or query parameters and simply call the apis, gathering the data together into a single object, and passing it down into the wrapped component as props similar to what something like Apollo would do.

This essentially means that we can use GraphQL style querying on any route that we can hit, whether it is in our control or not. You can see an example of this in action here.

We make some tradeoffs, giving up some of the great benefits that come with a true GraphQL api including but not limited to types, better control over resolution, constructing the picked objects on the server instead of the client, and probably many more things that I don’t even know about.

In my probably biased opinion though this gives us easier access to the greatest thing GraphQL brought to frontend development. Expressive components with their data needs colocated right alongside. We shouldn’t be prevented from using this paradigm because we don’t have a GraphQL backend, we should be encouraging this style of component development wherever we can, and the nice thing is if you ever did move to a GraphQl backend the rewrite from this becomes vastly simpler then just constructed ad hoc API calls.

The work here is far from done and I’m positive there are many cases I have not yet covered but I’m convinced that I’ve stumbled upon something that could be great, and any feedback you have would be greatly appreciated (seriously any feedback, tell me I’m completely wrong). As I’ve said throughout this post and I’ll reiterate now I think GraphQL fundamentally changed the way we work with data on the frontend, if you can have an app backed by a GraphQL server I think you should, but I don’t think we should be limited by this and I think this project can make big strides in removing that limitation.

The code is on github here if you would like to look at it. If nothing else I hope this post makes you think about what we can do to make our frontends and their increasingly complex data flows easier to reason about. In my opinion that’s colocated GraphQL or GraphQL style queries but if there’s something better I would love to here that too.

✌️

✉️ Subscribe to CodeBurst’s once-weekly Email Blast, 🐦 Follow CodeBurst on Twitter, view 🗺️ The 2018 Web Developer Roadmap, and 🕸️ Learn Full Stack Web Development.

RouteQL — GraphQL without the GraphQL was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

let me just get this right out of the way, i love graphql, it clicked for me as soon i read the first blog post about it.

at the time, i was primarily working on the front end of a large application, and the idea that i could have query syntax in the client with the ability to specify the exact shape of the data i was going to get back was amazing to me. and even better the schema on the server was typed so i wasn’t only going to know the shape of the data i was getting back, i was also going to be able to know the types 😍.

eventually i got the chance to use graphql on a project and it was everything i hoped for, using apollo on the client it was very clear what data every component needed at a glance, i no longer had to dig through internal api docs to find out what i was or wasn’t going to get back.

if everything was always rainbows and butterflies (shout out to adam levine) though i probably wouldn’t be writing this blog post. with multiple developers working on a project it can sometimes be impossible to keep track of everything. it’s very easy to change the schema on the server without making sure the schema change won’t cause errors to any of the queries on the client. i think someone said something once about humans making errors and it makes you human or something, i don’t know, graphql prevents a lot of those errors but it can’t really prevent the situation described above.

my coworker katherine thompson and i have been exploring how we can prevent the situations above and have come up with some solutions that i think are interesting enough to share with the larger community as they have definitely helped us deploy our applications safely and continuously.

the root of the issue is simple, when we deploy (or when we commit, or at 1:19 am on a sunday night when something is just eating away at us because it doesn’t feel quite right and we probably have others issues but right now we’re just thinking about graphql schema so get off our back ok) we want to be able to know that every query in our client app can be validly resolved against our server schema. to that end we’ve created a collection of packages that can either recurse over nested directories of graphql queries in .graphql files or over directories containing javascript files with inline queries written using the graphql-tag library (it will extract these queries first using a small utility library we’ve written — gql-extract — to first parse out the queries from the tagged template strings) and then auto generate tests for these queries against a provided application schema.

we’re providing this tooling in a package that allows for use as either a javascript api or a command line interface and you can find it here: graphql-test-generator.

we personally utilize this in a pre-test step to generate tests that are then immediately run in npm test stage. this gives us the comfort of being able to deploy knowing all the queries our application could potentially attempt are schema safe. here’s an excerpt from a package.json file illustrating our use:

{
  "pretest": "gqlTestExtraction -e ./src -o ./test -s    ../server/schema",    
  "test": "npm run lint && tape test/*.js"
}

and here is an example generated tests:

const { parse } = require("graphql/language");
const { validate } = require("graphql/validation");
const schema = require("../../tests/schema");
const query = `
    query getUserId {
        user {
            id
        }
    }
`;
const queryAST = parse(query);
const errors = validate(schema, queryAST);
const isValid = !errors.length;
const test = require("tape");
test("getUserId query adheres to application schema", assert => {
 assert.ok(isValid, "getUserId contains no schema errors");
 assert.end();
});;

by default a test using the tape library is generated but you can use an optional parameter to point to your own test generation function, an example of that can be found here — https://github.com/socialtables/graphql-test-generator/blob/master/tests/test-for-failure.js — in which we are testing that a query is not valid in order to try to provide some proof that the library avoids false positives. in the future if there’s an interest we may provide defaults for several frameworks instead of forcing the admittedly clunky interface for generating a custom test.

graphql and apollo have been extremely productive for us as a company (and me an individual) and i’m hopeful these tools can offer as much help for others as they have for my team.

the library definitely still has some warts and edge cases so i’d be super appreciative if you submitted any issues you found here: https://github.com/socialtables/graphql-test-generator/issues

testing the schema compliance of an applications graphql queries — why not do it automatically? was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

wow, that title is long, and i’m not even sure if it’s accurate. i read a lot of words and some of them i know, i hope i know the ones i used in the title.

anyway, moving on, as i explored in a previous post, we can use babel as more than just an esnext => espresent? compiler. here we’ll take a look at how we can use babel to make certain decisions for us at build time that would normally be deferred to runtime in order to hopefully speed up our applications.

imagine(or at least please try like really hard) that you have some sort of user permission system in your application that restricts access to some parts of your user interface based on permissions, you might wrap that ui in a component like this that restricts access to only those who can edit and shows some other component or nothing to those who can not.

<RequiredPermissions
  required={[“can_edit”]}
  permissions={this.props.permissions}
  notAllowedElement={<Error />}
>
  <textarea onChange={() => {}}>
    {this.props.content}
  </textarea>
</RequiredPermissions>

a lot of applications will have relatively few variants of these permission sets, you might have administrators, editors, and viewers for example. in cases like these, we can just build three separate bundles at build time that would move these run time decisions to build time decisions by injecting certain permission sets and using babel to replace the RequiredPermissions component with in this case, either children or notAllowedElement by doing something like this:

Then in our .babelrc

this will allow us to set the permissions for a particular permissions set on process.env.PERMISSIONS and than simply choose the branch and put that directly into the final compiled file instead of the RequiredPermissions component which will need to make the decision on whether or not the user can see something every time at run time.

this does force us to put some tooling around our build system and i haven’t come up with a great idea for that just yet but something like this should work:

the next step in the process would be removing the import everywhere where we were actually able to pre choose a branch but i haven’t quite gotten to that point yet. let me know if you have any ideas or other feedback, thanks for reading and i hope it was least semi interesting or informative.

using babel(and webpack) to make ahead of time render decisions for branched components at build… was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ll start this off by saying the client side bundles at my company are way too big, like really big, like upsettingly big.

I make myself feel better knowing they used to be way bigger, our apps are mostly used in modern browsers on ~modernish computers, and whatever other excuse I can come up with to not feel like I’m failing every moment of the day.

A lot of the performance talk on the internet (at least the stuff I run into) focuses on big sweeping changes, where we take a 7mb monolithic app and code split it into and walk outside and a stranger hands us a hundred dollars on the street, but my world doesn’t work this day. I like to focus on making the smallest changes that can make the biggest immediate improvements, sometimes you make the sweeping changes but usually time just doesn’t permit it.

We use a lot of svg icons in our React applications, and a lot of them are shared between applications, so we’ve wrapped some up in a shared library that is used by ~5 applications. You might imagine that `application a` is using 40 of these, `application b` is using 15 of these, and so on and so forth, you get the point, or maybe you don’t, usually it takes me a long time to get to no point at all.

Anyway, back to the svgs, since we’re not distributing esmodules right now, i noticed that although our apps were importing the icons like this:

import { Chair } from "@socialtables/icon-svg";

We would end up bundling all 226 (and growing) icons in the library. My first idea was just to push people towards doing direct imports as follows:

import Chair from "@socialtables/icon-svg/dist/chair";

but in that case all it takes is one person messing it up to end up bloating the bundle.

Webpack 2 is getting better here with warnings for bundle size but we still need to address the root issue, where I want to use syntax one but end up with the output of syntax two going into to my bundle.

To achieve this I wrote a babel plugin to find imports using syntax 1 and convert to syntax 2 style imports.

const componentToFileMapping = require("./component-mapping");

module.exports = function replace() {
  const visitor = {
    Program(path) {
      const file = path.hub.file;
      const imports = file.metadata.modules.imports;
      imports.forEach(imp => {
        if (imp.source === "@socialtables/icon-svg") {
          imp.specifiers.forEach(spec => {
              const imported = spec.imported;
              const local = spec.local;
              const binding = file.scope.getBinding(local);
              binding.referencePaths.forEach(refPath => {
                const type = refPath.node.type;
                if (imported && imported !== "default") {
                  const fileName = componentToFileMapping[imported];
                  const name = refPath.hub.file.addImport(
                      `@socialtables/icon-svg/dist/icon-components/${fileName}`,
                      "default",
                      imported
                  ).name;
                  refPath.replaceWith({ type, name });
                }
              });
          });
        }
      });
    },
    ImportDeclaration(path) {
      if (path.node.source.value === "@socialtables/icon-svg") {
        path.remove();
      }
    }
  }
  return { visitor };
}

I’m sure I’ve made mistakes here and would love feedback if you see some but at the heart of it we simply search the program ast for non default imports of icon-svg components and replace them with default imports to the specific component file (a lot of inspiration for this came from babel-plugin-lodash). This helps us save on bundle size without having to change developer workflow, and not allowing one “mistake” to shoot us in the foot. (Quick note, I super duper wish I knew about astexplorer.net when I made this so uhh, definitely use that if you’re going to do something similar.

In one of our applications this improved the bundle size by 710kb. The bundle is still oversized and needs a lot of work, but the ultimate point I think I’m trying to make is people think of babel as an esnext => current javascript compiler when it can really be so much more.

I’ve recently been experimenting with using babel to turn runtime decision making in branched React components into build time decisions generating different bundles, and hope to write about this soon.

If you read this far, thank you, because I don’t think I would have 🌟🆒✌🏻

How Babel helped to save 710kb from a production bundle and how it’s so much more than esnext… was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

Where Animals Live

Squerels live in trees,

birds live in nests,

bears live in caves,

some run wild in the woods,

some live in the zoo,

and thats where some animals live.

Wild Horse

The wild wind rumbles thrue

the night like a wild horse in my sight

the wild horse runs runs until i cetch him

out of this world into the wonderful world next door

There were two kids, their names were Anthony and Steven. They both love basketball but it’s just that they weren’t too good at it. They practiced every day but they still weren’t too good. But they didn’t give up
The next day they had a game. All the kids made fun of them because they each had only 2 points and 1 rebound.

After the game Anthony and Steven walked home together. Steven was going to a wedding. He wouldn’t be back until one o’clock. Anthony was sad he had no one to play with. When Steven got back from the wedding Anthony was so happy. He asked Steven if he wanted to play basketball. He said okay. At first they were doing the same old thing, just missing every shot. Then suddenly out of nowhere came the ghost of basketball.
“Hello kids! I won’t scare you. I’m going to teach you how to play basketball! Okay now come on let’s play! Okay first I’m going to teach you how to shoot. First put one hand in the middle and one hand on the side then bend and shoot. Good! I’ve got to go to some other houses. Keep trying and I’ll be at your game Sunday.”

On sunday everyone made fun of them again because the next game they still didn’t do so well. Only Steven had 3 points but the three points still had them down by two. Anthony hit a three pointer at the buzzer to win the game. Everyone cheered for him. He had won the game. Everyone picked him up over their shoulders .

Now they had confidence and they had friends and that’s all that matters.

nah

Social Tables Ultimate Developer Institute was originally published in Social Tables Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.