Revamp TypeScript typing with more type safety #2563

pelotom · 2017-08-16T20:05:30Z

This fixes many issues with the current TypeScript typings, while remaining mostly* backwards compatible:

Add a type parameter to Action tracking the type of the type tag.
Stop using the irrelevant state type param on Dispatch (but keep it around for backwards compatibility).
Add a type parameter to Dispatch which is the type of things which may be dispatched (previously Dispatch had a polymorphic apply which allowed anything to be dispatched).
Add type parameters A and N to Store which respectively track the actions it may dispatch and all other non-action things which may be dispatched. Then its dispatch method can take A | N.
Add a type parameter A to Reducer which tracks the actions it understands, instead of just using AnyAction.
Use type parameter defaulting everywhere to make this as backwards-compatible as possible.

With these changes, type inference for a lot of redux functions improves dramatically, and thus we get more type safety with less effort. I won't pretend these are perfect; in particular I think the middleware/enhancer functions could use some work to make the N variables accumulate as appropriate, but it's hopefully a step in the right direction.

As part of this, upgraded the TypeScript dependency to ^2.4.2.

* As you can see from some of the modified testcases, in a few rare cases it's necessary to modify type parameter annotations, e.g. when calling combineReducers.

pelotom · 2017-08-16T22:43:11Z

test/typescript/compose.ts

@@ -36,4 +36,4 @@ const t11: number = compose(stringToNumber, numberToString, stringToNumber,


 const funcs = [stringToNumber, numberToString, stringToNumber];
-const t12 = compose(...funcs)('bar', 42, true);


This appears to have just been a bug in the old test case, which the newer version of TypeScript caught.

aikoven · 2017-08-17T05:06:04Z

index.d.ts

-export interface AnyAction extends Action {
-  // Allows any extra properties to be defined in an action.
-  [extraProps: string]: any;
+export interface Action<T = any> {


Am I right that the intended use case for the type argument is using string literal types?

aikoven · 2017-08-17T05:09:07Z

index.d.ts

 */
-export type Reducer<S> = (state: S, action: AnyAction) => S;
+export type Reducer<S = {}, A extends Action = Action> = (state: S, action: A) => S;


Is there a particular reason for S to default to {}?

Also, I don't think that it is correct to constraint the type of action. A reducer must be able to accept every possible action, which is any object with type property. It should just ignore all actions that don't affect its state.

Is there a particular reason for S to default to {}?

Not really, I was just on a defaulting rampage.

Also, I don't think that it is correct to constraint the type of action. A reducer must be able to accept every possible action, which is any object with type property. It should just ignore all actions that don't affect its state.

It's perfectly valid to constrain the type of actions that a reducer handles. It must be able to accept any action in your app, but not any arbitrary object with a type field. This is critical to making the library nice to use in TypeScript because it allows the type system to automatically refine the types for you as you learn information by inspecting the type field. For example:

// The universe of all actions used in your app export type AnyAction = | SetGreeting | IncrementCounter | SetCompletionStatus export interface SetGreeting { type: 'SET_GREETING' greeting: string } export interface IncrementCounter { type: 'INCREMENT_COUNTER' counterIndex: number } export interface SetCompletionStatus { type: 'SET_COMPLETION_STATUS' completed: boolean } const reducer: Reducer<State, AnyAction> = (state = initialState, action) => { switch (action.type) { case: 'SET_GREETING': return { ...state, greeting: action.greeting } case: 'INCREMENT_COUNTER': return { ...state, counters: state.counters[action.counterIndex] + 1 } case: 'SET_COMPLETION_STATUS': return { ...state, completed: action.completed } } }

What's super cool about this is

It's completely type safe. Inside each case, the type of action has been refined such that it knows what fields should be available on it and what types they have. If I tried to access action.counterIndex in a branch where I hadn't checked that action.type === 'INCREMENT_COUNTER' it would be a type error.

We get exhaustiveness checking, so that no default case is required because the type system has proven that you've handled all possible action types.

You can perform an app-wide refactoring on the string literals being used for the action type fields and they will also change these switch cases.

There's always an init action which is internal to Redux whose type can potentially be made random.

Yes, but your app can pretend that doesn't exist for all intents and purposes.

To me making types that don't agree with the runtime is an abuse of type system.

However, I can see that this approach gives really nice DX, so I tend to agree with you. It should be up to developer to decide the level of strictness they want.

You could certainly opt to include the init action in your top-level union of action types if you want to capture absolutely all actions that might be passing through your reducer. The point is to constrain the types to some known, closed universe so that you can have type safety and semantic awareness for refactoring.

aikoven · 2017-08-17T05:10:46Z

index.d.ts

-export interface ReducersMapObject {
-  [key: string]: Reducer<any>;
+export type ReducersMapObject<S = {}, A extends Action = Action> = {
+  [K in keyof S]: Reducer<S[K], A>;


Already done on the next branch: https://github.com/reactjs/redux/blob/next/index.d.ts#L52

This PR should probably target the next.

Ok, I'll do that.

aikoven · 2017-08-17T08:10:00Z

index.d.ts

- * This is not part of `Action` itself to prevent users who are extending `Action.
- * @private
- */
-export interface AnyAction extends Action {


Are you sure AnyAction can be safely removed? Its absence broke stuff on TS 2.4

See #2467

Yes, since Reducers are parameterized by action type now it should no longer be necessary.

timwangdev · 2017-09-02T14:09:11Z

Looking forward to see any updates on this PR

pelotom · 2017-09-11T18:29:31Z

Rebased this onto next as requested, afaik it should be good to merge.

aikoven · 2017-09-12T04:01:33Z

index.d.ts

 */
-export type Reducer<S> = <A extends Action>(state: S | undefined, action: A) => S;
+export type Reducer<S = {}, A extends Action = Action> = (state: S | undefined, action: A) => S;


Still, do we really want to have S default to {}? Why?

I was trying to keep this PR as backwards-compatible as possible, but if that's not important I'm more than happy to remove it.

Sorry, I don't get how it aids backward compatibility. Previous Reducer type did have S as a required parameter.

Hm, I appear to have been confused when I made this comment. I was thinking of the state parameter to the Dispatch type, which is completely unnecessary but I was keeping around for backwards compatibility.

The argument for defaulting S here is the same as for ReducersMapObject and Store below... so that we can declare type constraints like R extends Reducer when we don't care about the type arguments.

Thanks, this makes sense. The only thing that bothers me: if the state type of reducer includes null, that reducer won't be assignable to Reducer (without parameters).

A very simplified example:

type Reducer<S = {}> = (state: S | undefined) => S; const r: Reducer = (state: null | undefined = null): null => { return state; }

Gives

Type '(state?: null | undefined) => null' is not assignable to type 'Reducer<{}>'. Types of parameters 'state' and 'state' are incompatible. Type '{} | undefined' is not assignable to type 'null | undefined'. Type '{}' is not assignable to type 'null | undefined'. Type '{}' is not assignable to type 'null'.

Works fine after setting S = {} | null.

I think you're right, except that undefined for the state is prohibited by Redux. Yet I'm not sure if we gain any type safety by excluding it.

As far as I know, {} | null | undefined is the same as any.

Remember though, undefined is prohibited to return from a reducer but not as argument, which is passed with the initial call.

It's not quite the same, because for example

declare x: {} | null | undefined x.foo // this is a type error declare y: any y.foo // this is fine

any isn't really a type, it's more like a directive not to perform type checking. I'd say {} | null is the most "correct" thing to use here, but a lot of people tend to use any in situations like this because it's easy on the eyes. I could go either way.

Remember though, undefined is prohibited to return from a reducer but not as argument, which is passed with the initial call.

The definition covers this since the state argument is of type S | undefined.

It's not quite the same

You are right, I used the wrong word. They are equivalent in terms of assignability.

aikoven · 2017-09-12T04:02:40Z

index.d.ts

 */
-export type ReducersMapObject<S> = {
-  [K in keyof S]: Reducer<S[K]>;
+export type ReducersMapObject<S = {}, A extends Action = Action> = {


Default for S here is unclear for me too.

Having defaults means you can just reference ReducersMapObject if you don't care about the types involved. That tends to happen if you have a generic type parameter T extends ReducersMapObject for example.

This makes some sense. But wouldn't ReducersMapObject<{}> be the same as just {}? Therefore T extends {} only means that T is not null or undefined.

You raise a good point and I think it means I chose the wrong default... instead it should be { [k: string]: any }. That way ReducersMapObject should be equivalent to { [k: string]: Reducer<any> }?

Yeah, I think that should work.

aikoven · 2017-09-12T04:03:01Z

index.d.ts

@@ -70,7 +75,7 @@ export type ReducersMapObject<S> = {
 * @returns A reducer function that invokes every reducer inside the passed
 *   object, and builds a state object with the same shape.
 */
-export function combineReducers<S>(reducers: ReducersMapObject<S>): Reducer<S>;
+export function combineReducers<S, A extends Action>(reducers: ReducersMapObject<S, A>): Reducer<S, A>;


Let's add a default type for A

aikoven · 2017-09-12T04:32:13Z

index.d.ts

@@ -92,9 +97,12 @@ export function combineReducers<S>(reducers: ReducersMapObject<S>): Reducer<S>;
 * function to handle async actions in addition to actions. Middleware may
 * transform, delay, ignore, or otherwise interpret actions or async actions
 * before passing them to the next middleware.
+ *
+ * @template S unused, here only for backwards compatibility.


I think we should put more thought into this. These changes are already breaking, so why should we bother about compatibility here?

The S type parameter brought much more misconception and inconvenience than benefit. It was initially added to allow us to strongly type-check dispatching thunks: as you can see here, we augment the Dispatch interface to add a new signature for thunks that uses S.

But in real-world it appeared that we rarely use dispatch as a method of the Store, where it has a fixed state type, but rather as an injected function (like in react-redux), where we have to declare its type manually:

const mapDispatchToProps = (dispatch: Dispatch<MyState>) => ...

For users who don't use redux-thunk this led to annoying need to write Dispatch<any> instead of just Dispatch.

We could just remove S altogether to simplify things; redux-thunk users would still be able to get partial type safety by declaring their state type in ThunkAction type parameters. The one major drawback of this is that it would make it much harder to migrate to the new typings.

Otherwise we should make this docstring point to the use case of S.

As I said I'm happy to remove the state parameter and I definitely think this should be done at some point... If you think this PR is the right place for it I'll remove it.

aikoven · 2017-09-12T04:33:23Z

index.d.ts

 */
-export interface Store<S> {
+export interface Store<S = {}, A extends Action = Action, N = never> {


Again, the default for S is unclear.

See previous comment... if that doesn't sway you, I'll remove the default.

aikoven · 2017-09-12T04:37:29Z

index.d.ts

 */
-export interface Store<S> {
+export interface Store<S = {}, A extends Action = Action, N = never> {


Dispatching non-actions is handled by augmenting the Dispatch interface. There's a difference between that and adding another type to the union: for example, when dispatching a thunk, dispatch returns the return value of the thunk, not the thunk itself.

So are you advocating removal of the N parameter?

Please don't. Augmenting Dispatch for things like redux-thunk is broken, see reduxjs/redux-thunk#82. Still no one gave a solution how typing middlewares can work when redux-thunk has augmented Dispatch.

I agree that module augmentation is more of a workaround rather than an ideal solution.

Still, it gives us something that we can't achieve with just extending the type of dispatch argument: it allows us to set up a mapping from input type to output type of dispatch calls, which is different from one middleware to another.
Having just Dispatch<Action | ThunkAction> is incorrect, because it will work as if dispatch(thunk) returned the thunk itself.

Also, from what I see in the issue, the error comes from the definition of Middleware, and not from the module augmentation.

Considering the ideal solution: adding dispatch signatures happens during store enhancement by applyMiddleware(...). We could try to come up with smarter typings for StoreEnhancer and Middleware to get signature augmentation without module augmentation. Back then we didn't succeed with it, but now TS is much more powerful.

#1526
#1648

Maybe the Dispatch type should still take 2 type parameters, but one is the input ("action") type, and one is the output type?

Maybe the Dispatch type should still take 2 type parameters, but one is the input ("action") type, and one is the output type?

Sounds good to me.

After thinking a bit more about it, I don't think that improves it. Using a union type for the Action and a union type for the return value does not really help here (e.g. with redux-thunk). What you need instead is two different signatures (overloaded functions). I'm thinking the Action shouldn't be the type param (for Store and Middleware) but instead the whole Dispatch should be.

aikoven · 2017-09-12T09:08:42Z

Guys, let's continue our discussion here instead of code comments because they get hidden after code updates.

I'm thinking the Action shouldn't be the type param (for Store and Middleware) but instead the whole Dispatch should be.

I think that's the way to go. The type for Middleware would be something like

interface Middleware<NewDispatch> {
  (api: MiddlewareAPI): (next: Dispatch) => Dispatch | NewDispatch;
}

But there's one problem: NewDispatch can potentially be generic, and I don't know of a way to have a generic type as a type parameter. E.g. in redux-thunk our NewDispatch would have the state type as a type parameter, and we need to somehow make it the same as in MiddlewareAPI.

unstubbable · 2017-09-12T09:54:30Z

This is tricky. If you think this further, than the MiddlewareAPI interface would probably be defined like this:

export interface MiddlewareAPI<S = any, D = Dispatch> {
  dispatch: D;
  getState(): S;
}

But then in the Middleware interface you couldn't decide whether to set Dispatch or NewDispatch on MiddlewareAPI because this depends on whether the middleware is the left-most in applyMiddleware, right?

EDIT: Or you could just say api: MiddlewareAPI<S, Dispatch | NewDispatch> I guess.

unstubbable · 2017-09-12T10:03:31Z

@aikoven To answer your question, wouldn't this be sufficient?

export interface MiddlewareAPI<S = any, D = Dispatch> {
  dispatch: D;
  getState(): S;
}

export interface Middleware<NewDispatch = Dispatch, D = Dispatch> {
  <S = any>(api: MiddlewareAPI<S, NewDispatch | D>): (
    next: D
  ) => NewDispatch | D;
}

And in redux-thunk:

import {Middleware, Dispatch as ReduxDispatch} from 'redux';

export type ThunkAction<A, R, S, E> = (
  dispatch: Dispatch<A>,
  getState: () => S,
  extraArgument: E
) => R;

export interface Dispatch<A> extends ReduxDispatch<A> {
  <R, S, E>(asyncAction: ThunkAction<A, R, S, E>): R;
}

declare const thunk: Middleware<Dispatch<any>> & {
  withExtraArgument(extraArgument: any): Middleware<Dispatch<any>>;
};

export default thunk;

The any doesn't hurt here, does it?

unstubbable · 2017-09-12T10:30:46Z

That does not compile though in my current project (using the Dispatch interface from redux-thunk in thunks). The problem is the action type. We want to define the action type attribute with either a string literal union type or a string enum (which I prefer since this became available) so TS can narrow down the payload type in a switch for example. But if you also handle other actions without such a type, e.g. LocationChangeAction and RouterAction from react-router-redux, you can not put them in your Action union type because this breaks the type narrowing based on the type. This can only be solved by defining Dispatch (in your project) like this:

import {
  LocationChangeAction,
  RouterAction,
  RouterState,
} from 'react-router-redux';
import {ThunkAction as ReduxThunkAction} from 'redux-thunk';

import {Action} from '../src/actions';

export interface AppState {
  routing: RouterState;
  ...
}

export type ThunkAction<Result> = ReduxThunkAction<
  Action,
  Result,
  AppState,
  undefined
>;

export interface Dispatch {
  <Result>(action: ThunkAction<Result>): Result;
  (action: LocationChangeAction | RouterAction):
    | LocationChangeAction
    | RouterAction;
  (action: Action): Action;
}

This Dispatch interface can then be used in thunks.

pelotom · 2017-09-15T18:24:59Z

It seems like fixing the type of Dispatch in an ideal way still has some issues to be worked through. Is there any reason not to merge this PR in the meantime? Let's not let perfect be the enemy of good.

aikoven · 2017-09-26T09:31:52Z

@pelotom The only thing that bothers me is the N parameter. I don't see it as a viable solution and it will be very hard to transition from it if it gets to a release.

I am pretty sure there exists a good solution for Dispatch extension, although it may be subject for another PR.

Otherwise, the changes look very well done to me.

timdorr · 2017-10-06T01:04:18Z

OK, I'm merging it in!

* Revamp TypeScript typing with more type safety * Provide a default action type for combineReducers * Change state default types to any * Don't parameterize Dispatch with a state type * Remove docstring about excised type parameter

timdorr · 2017-10-22T22:16:55Z

Because we didn't have next on the CI config, this didn't get tests run. Turns out, there's a breakage:

Via https://travis-ci.org/reactjs/redux/builds/291276494
FAIL test/typescript.spec.js
● TypeScript definitions › should compile against index.d.ts
AssertionError: Semantic: /home/travis/build/reactjs/redux/index.d.ts (103,18): All declarations of 'Dispatch' must have identical type parameters.

@pelotom @aikoven @KingHenne or anyone else want to provide a fix? I'd like to push forward on Redux 4.0 and this is a blocker.

pelotom · 2017-10-22T22:30:18Z

@timdorr hmm, what am I doing wrong?

> yarn test
yarn run v1.2.1
$ cross-env BABEL_ENV=commonjs jest
 PASS  test/typescript.spec.js
 PASS  test/createStore.spec.js
 PASS  test/bindActionCreators.spec.js
 PASS  test/compose.spec.js
 PASS  test/combineReducers.spec.js
 PASS  test/applyMiddleware.spec.js
 PASS  test/utils/warning.spec.js

pelotom · 2017-10-22T22:37:15Z

Never mind, I reproduced it now.

pelotom · 2017-10-22T23:06:31Z

@timdorr opened a PR: #2674

* Revamp TypeScript typing with more type safety * Provide a default action type for combineReducers * Change state default types to any * Don't parameterize Dispatch with a state type * Remove docstring about excised type parameter

domachine · 2017-12-06T08:07:23Z

So glad that this got merged. Is there anything I can help to get this released to npm?

timdorr · 2017-12-06T14:47:50Z

It's in 4.0.0-beta.1. npm install redux@next

domachine · 2017-12-06T15:15:23Z

Ah great! Thank you so much.

* Revamp TypeScript typing with more type safety * Provide a default action type for combineReducers * Change state default types to any * Don't parameterize Dispatch with a state type * Remove docstring about excised type parameter

pelotom commented Aug 16, 2017

View reviewed changes

aikoven reviewed Aug 17, 2017

View reviewed changes

This was referenced Sep 1, 2017

[TypeScript] Add Dispatch default any type parameter #2597

Closed

Fix the definition of 'AnyAction' #2517

Closed

Improve typings for Middleware #2530

Closed

unstubbable mentioned this pull request Sep 4, 2017

TypeScript Error in Middleware reduxjs/redux-thunk#82

Closed

pelotom changed the base branch from master to next September 11, 2017 17:37

pelotom force-pushed the patch-1 branch from 8d8b188 to 271d6d2 Compare September 11, 2017 18:08

Revamp TypeScript typing with more type safety

0dd93d1

pelotom force-pushed the patch-1 branch from 271d6d2 to 0dd93d1 Compare September 11, 2017 18:25

aikoven reviewed Sep 12, 2017

View reviewed changes

pelotom added 4 commits September 11, 2017 22:14

Provide a default action type for combineReducers

299b0b7

Change state default types to any

a76e708

Don't parameterize Dispatch with a state type

813fbff

Remove docstring about excised type parameter

4f5c320

MichalLytek approved these changes Sep 17, 2017

View reviewed changes

mmkal mentioned this pull request Sep 24, 2017

use mapped type for combineReducers #2623

Closed

samfrances mentioned this pull request Oct 5, 2017

Typescript: action type parameter for Store, Dispatch, etc. #2643

Closed

timdorr merged commit 7bea62a into reduxjs:next Oct 6, 2017

timdorr mentioned this pull request Oct 6, 2017

Dispatch interface should not be generic #2380

Closed

pelotom deleted the patch-1 branch October 22, 2017 22:30

pelotom mentioned this pull request Oct 24, 2017

Add TypeScript typings corresponding to redux@next reduxjs/react-redux#812

Closed

in19farkt mentioned this pull request Nov 7, 2017

Updated typescript to 2.1v. Improved type for combineReducers function. #2700

Closed

aikoven mentioned this pull request Dec 21, 2017

Update TypeScript typings #2773

Merged

pelotom mentioned this pull request Apr 26, 2018

Question regarding latest (beta.43) WithStyles update. mui/material-ui#11109

Closed

1 task

felipeochoa mentioned this pull request Apr 30, 2018

Set redux-batched-subscribe semver limit to <4.0.0 DefinitelyTyped/DefinitelyTyped#25423

Merged

9 tasks

AbraaoAlves mentioned this pull request May 23, 2019

Typescript support for Redux4 pauldijou/redux-act#100

Merged

snyk-bot mentioned this pull request Aug 30, 2019

[Snyk] Upgrade redux from 4.0.0 to 4.0.4 iliutastoica/react-slingshot#4

Open

snyk-bot mentioned this pull request Sep 23, 2019

[Snyk] Upgrade redux from 4.0.0 to 4.0.4 maxiplux/ReduxSimpleStarter#4

Merged

snyk-bot mentioned this pull request Oct 26, 2019

[Snyk] Upgrade redux from 3.7.2 to 4.0.4 ajesse11x/redux#5

Open

snyk-bot mentioned this pull request Nov 25, 2019

[Snyk] Upgrade redux from 3.7.2 to 4.0.4 ajesse11x/redux#10

Open

snyk-bot mentioned this pull request Mar 14, 2020

[Snyk] Upgrade redux from 4.0.0 to 4.0.5 xalpinistx/ExpressProject#10

Merged

snyk-bot mentioned this pull request Mar 23, 2020

[Snyk] Upgrade redux from 4.0.0 to 4.0.5 viddo/atom-textual-velocity#516

Merged

snyk-bot mentioned this pull request Apr 26, 2020

[Snyk] Upgrade redux from 4.0.0 to 4.0.5 terrestris/gondolin-client#9

Open

This was referenced Jun 6, 2020

Reducers are not typesafe and behave incorrectly in the default case of the switch #3792

Closed

LoopReducer is not type safe redux-loop/redux-loop#247

Closed

		@@ -36,4 +36,4 @@ const t11: number = compose(stringToNumber, numberToString, stringToNumber,


		const funcs = [stringToNumber, numberToString, stringToNumber];
		const t12 = compose(...funcs)('bar', 42, true);

Revamp TypeScript typing with more type safety #2563

Revamp TypeScript typing with more type safety #2563

Conversation

pelotom commented Aug 16, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

timwangdev commented Sep 2, 2017

pelotom commented Sep 11, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pelotom Sep 12, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

unstubbable Sep 12, 2017 • edited Loading

Choose a reason for hiding this comment

aikoven commented Sep 12, 2017

unstubbable commented Sep 12, 2017 • edited Loading

unstubbable commented Sep 12, 2017 • edited Loading

unstubbable commented Sep 12, 2017 • edited Loading

pelotom commented Sep 15, 2017

aikoven commented Sep 26, 2017

timdorr commented Oct 6, 2017

timdorr commented Oct 22, 2017

pelotom commented Oct 22, 2017

pelotom commented Oct 22, 2017

pelotom commented Oct 22, 2017

domachine commented Dec 6, 2017

timdorr commented Dec 6, 2017

domachine commented Dec 6, 2017

pelotom commented Aug 16, 2017 •

edited

Loading

pelotom Sep 12, 2017 •

edited

Loading

unstubbable Sep 12, 2017 •

edited

Loading

unstubbable commented Sep 12, 2017 •

edited

Loading

unstubbable commented Sep 12, 2017 •

edited

Loading

unstubbable commented Sep 12, 2017 •

edited

Loading