Michel Weststrate mweststrate

Decorators: yet another proposal

Introduction

Decorators are a proposal for extending JavaScript classes which is widely adopted among developers in transpiler environments, with broad interest in standardization. TC39 has been iterating on decorators proposals for over five years. This document describes a new proposal for decorators based on elements from all past proposals.

Decorators @decorator are functions called on class elements or other JavaScript syntax forms during definition, potentially wrapping or replacing them with a new value returned by the decorator.

A decorated class field is treated as wrapping a getter/setter pair for accessing that storage. Decorated storage is useful for observation/tracking, which has been a pain point for the original legacy/experimental decorators combined with [[Define]] semantics for class fields. These semantics are based on Michel Weststrate's "trapping decorators" proposal.

1: Intro

Welcome to the interactive tutorial on how to use side-effect "operators" in MobX! Over the course of the next three samples, you'll learn (and be able to explore) exactly how autorun, when and reaction work, and when/why you would use them when building reactive applications.

What is RNRF (react-native-router-flux)?

React Native is great product but lacks for stable, intuitive and easy navigation API during many years. Every year we see new, better API: Native Navigator, ex-Navigator, NavigationExperimental, ex-Navigation, wix native navigation, airbnb native navigation, ReactNavigation...

Once I've started React Native development, in 2015, I created RNRF - simple API for easy navigation. It was clear that better navigation instruments will come later but I didn't want to change my code again and again to switch for better API. Every new major version of RNRF is based on different navigation framework and mostly preserves own API.

Another goal was to represent all navigation flow within one place in clear, human-readable way - similar to iOS Storyboards concept. This way other engineers could understand your app flow faster.

How do you make friends with React and FRP? 🤔 Start to develop your application using Focal.

This is a CFP for the ⚡️Lightning⚡️ talk at awesome ReactiveConf 2017. If you'd like to see this talk, please 🌟 star🌟 this summary and retweet my tweet 🙂 #ReactiveConf

Functional reactive programming (FRP) is very popular nowadays. The JavaScript community provides us with excellent tools like RxJS, Bacon, and Kefir. But, as we know, they have nothing to do with React. So how we can use the power of FRP in our React application? Using the correct state management, we can make friends with FRP and React and make our application truly reactive. In my lightning talk, I will talk about Focal

--> Star this gist if you want to see it on the Reactive 2016 conference <--

Writing React.js is fun... But being able to draw React components, design responsive layouts and create entire app flows visually can be even more fun! (Especially for those non-coder members of your team who think ECMAScript 6 is a skin disease. They should see the light of React too.)

In this lightning talk, we'll give you a world premiere sneak peek at React Studio (www.reactstudio.com), a GUI tool built specifically for React. We'll explain how React's functional design makes it a great fit for visual tools. Also we will show how React Studio's plugin approach makes it a really powerful meta-programming system. Want to switch your app from Redux to Alt.js or vice versa? Just swap the state plugin and export again! That's just one of the joys of using a visual system for your Reactified visual design.

https://reactiveconf.com

This is a proposal for a ⚡lightning talk at the Reactive 2016 conference.

🌟Star this gist if you want to see it on the conference.

Introduction to BDSM

Every day we work with multiple teams to build our products, communication and sync are key factors to deliver your product on time without compromising quality.

In this talk I will introduce BDSM a new mocking tool that will change the way you coordinate between client and server teams minimizing friction allowing each team to work at its own pace while keeping in sync.

	const React = require('react');

	const __DEV__ = process.env.NODE_ENV !== 'production';
	const HOOK_NAME = 'useDerivedState';
	const NO_DEPS_HINT = 'If there are no dependencies, use "const [state] = useState(fn)"'

	/**
	* Copied from from React sources and adjusted
	* inlined Object.is polyfill to avoid requiring consumers ship their own
	* https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/is

	class Foo {
	constructor(x) { this.foo = x; }
	hello() { console.log(this.foo); }
	}

	class Bar extends Foo {
	constructor(x) { super(x); this.bar = x * 100; }
	world() { console.log(this.bar); }
	}

	import produce from 'immer';
	import {createStore} from 'redux';

	const handleActions = (actionsMap, defaultState) => (
	state = defaultState,
	{type, payload}
	) =>
	produce(state, draft => {
	const action = actionsMap[type];
	action && action(draft, payload);

	"Redux forces you to write good code" - I've heard that sentence many times.
	In fact - it's quite easy to write bad code with Redux, as I've seen many times.

	In this talk I will show some bad practices and techniques with Redux, and how to avoid them.