Skip to content

Instantly share code, notes, and snippets.

View reason-merlin-editor-setup.md

Reason

I have heard a lot of complaints about lack of editor integration or flaky editor tooling in the Reason community. At my previous job we had ~3000 modules and ~80k LOC. I'll admit that we were not very vigilant with .rei files or keeping our inter module dependencies really clean so this slowed both bsb and especially reason-language-server down a lot.

In fact so much that people couldn't use reason-language-server anymore on 15" MacBook Pros.

I myself have always used a Merlin based setup since I joined the Reason eco system before reason-language-server, and in our project my setup had never failed. Therefor I went on a quest of setting up 3 of the major editors (Emacs, Vim and VSCode) and documenting how to get them working

@elnygren
elnygren / I18n.re
Last active Jan 16, 2020
Simple ReasonML i18n internationalization example with strong static typing and JS/TS support with GenType
View I18n.re
/** Schema for translations, with @genType for TS/JS usage */
[@genType]
type translations = {
helloMessage: string,
helloMessageWithVariable: (~name: string) => string,
};
/** English translations */
[@genType]
let translationsEN = {
@jaredly
jaredly / App.re
Last active Jan 1, 2021
ReasonReact Context API Example
View App.re
module StringContext =
Context.MakePair({
type t = string;
let defaultValue = "Awesome";
});
let component = ReasonReact.statelessComponent("Tree");
let make = _children => {
@skylineproject
skylineproject / clean-react-native-app.sh
Last active Jan 7, 2019
A quick helper util for getting a misbehaving React Native environment back to normal.
View clean-react-native-app.sh
alias clean-rn="watchman watch-del-all && rm -fr $TMPDIR/npm* && rm -rf $TMPDIR/react-* && rm -rf node_modules/ && yarn cache clean && rm -rf ios/build && rm -rf ios/Pods && rm -rf android/.gradle && rm -rf android/.idea && rm -rf android/build && rm -rf android/app/build && rm -rf android/app/app.iml && yarn"
View types.markdown

This document has moved!

It's now here, in The Programmer's Compendium. The content is the same as before, but being part of the compendium means that it's actively maintained.

View actor.js
const getAllPropertyNames = require('./get_all_property_names'),
Mutex = require('./mutex')
function actor(object) {
let methods = getAllPropertyNames(object),
mutex = new Mutex(),
wrapper = {}
for (let method of methods) {
if (typeof object[method] !== 'function') continue
@scottjehl
scottjehl / notes.md
Last active Feb 27, 2021
Notes from Wes Bos's talk on web tooling
View notes.md

Notes from @wesbos's talk:

Our frontend workflow is changing quickly and for good reasons. Tooling for tooling sake is a waste, but don't overlook the utility of modern dev tooling workflows - these are great, useful tools that are letting us improve our workflows in standards-based, forward-looking ways.

Trend: Frontend developers are moving to using package managers (npm) for client-side code (CSS and JS), much like we have been for managing our build tooling itself. I can attest to this being hugely helpful at Filament Group on client-side code, especially now that so many of our projects are on npm (https://www.npmjs.com/~filamentgroup ).

Yay, another talk that recommends loadCSS for performance. Nice to hear :)

Gulp tasks to use:

@dmvaldman
dmvaldman / FRPandPhilosophy.md
Last active Oct 30, 2020
Descartes, Berkeley and Functional Reactive Programming
View FRPandPhilosophy.md

Descartes, Berkeley and Functional Reactive Programming

By @dmvaldman

Functional Reactive Programming (FRP) is generating buzz as an alternative to Object Oriented Programming (OOP) for certain use cases. However, an internet search quickly leads a curious and optimistic reader into the rabbit-hole of monads, functors, and other technical jargon. I’ve since emerged from this dark and lonely place with the realization that these words are mere implementation details, and that the core concepts are far more universal. In fact, the groundwork was laid down many centuries before the first computer, and has more to do with interpretations of reality, than structuring programs. Allow me to explain.

There’s an old thought experiment that goes like this:

Tree

View on-jsx.markdown

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

View README.md

react-arduino

React has revolutionized the way we write user interfaces. It brings an extremely simple mental model to the authoring of UIs. React-native, react-canvas, and other projects have shown us that this model extends beyond the browser DOM.

I believe that this functional, predictable approach can also revolutionize how we build real-world user interfaces.