jeffmo

ES7 Class Properties

**~~ NOTE: This is a Stage 0 proposal. ~~**

This proposal has been moved to https://github.com/jeffmo/es-class-properties.

Please direct all future feedback to that repo in the form of directed issues.

xpepper

(from SOLID Principles with Uncle Bob - Robert C. Martin - http://www.hanselminutes.com/145/solid-principles-with-uncle-bob-robert-c-martin)

Single Responsibility Principle, what does it mean? It means that a software module should have one reason to change, then that's what I call a responsibility, a reason to change.

So for example, take a payroll application, if there's an employee class in that payroll application, you could imagine that it might have methods for calculate pay or perhaps another method for print a report, perhaps another method in the employee object for save me to the database, and what's unfortunate about these three methods existing in the same class is that they have all three completely different reasons to change. The payroll, the calculate pay will change if the accountants decides on a new way of calculating pay. The report generator will change if the people who consume the reports want the format of the reports to change. The save function will change if the DBA's decid

pstoica

function OnBlurComponent({ onBlur }) {
  const handleBlur = (e) => {
    const currentTarget = e.currentTarget;

    // Check the newly focused element in the next tick of the event loop
    setTimeout(() => {
      // Check if the new activeElement is a child of the original container
      if (!currentTarget.contains(document.activeElement)) {
        // You can invoke a callback or add custom logic here
        onBlur();

proudlygeek

function callbackCurry(callbacks) {
    var memoize = function memoize(xs) {
        if (!xs.length) return null;

        var tail = xs.slice(1),
            head = xs[0];

        return head.bind(undefined, memoize(tail));
    };

debergalis

Brief notes on Meteor for CS 294-101. Many of the key architectural ideas in Meteor are described at https://www.meteor.com/projects.

1. BSD as example of great system design. Application primitives: processes run by a scheduler, sockets, sys calls, virtual memory, mbufs. What makes something a platform. Unix vs Multics.

2. History of application architectures. Mainframes (e.g. IBM 360 / 3270), client-server (e.g. Win32), web (e.g. LAMP), cloud-client. Oscillation of where the software runs. Thin vs thick clients, data vs presentation on the wire. Changes driven by massive forces (cheap CPUs, ubiquitous internet, mobile). New architecture for each era.

3. What it takes to make modern UI/UX. Mobile. Live updating. Collaboration. No refresh button. All drive the need for “realtime” or “reactive” system. Very different from HTTP era.

4. Four questions: 1 — how do we move data around; 2 — where does it come from; 3 — where do we put it; 4 — how do we use it?

chantastic

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

aldraco

// @N is the amount you are making change for
// @coins is the set of coin values you can use

function makeChange(N, coins) {
    // initialize the 'ways' array
    var answers = [];
    for (var n = 1; n <= N; n++) {
        answers[n] = 0;
    }
    // there is only one way of doing 0 cents?

idibidiart

Building a Maintainable, Agile Architecture for Realtime, Transactional Apps

A maintainable application architecture requires that the UI only contain the rendering logic and execute queries and mutations against the underlying data model on the server. A maintainable architecture must not contain any logic for composing "app state" on the client as that would necessarily embed business logic in the client. App state should be persisted to the database and the client projection of it should be composed in the mid tier, and refreshed as mutations occur on the server (and after network interruption) for a highly interactive, realtime UX.

With GraphQL we are able to define an easy-to-change application-level data schema on the server that captures the types and relationships in our data, and wiring it to data sources via resolvers that leverage our db's own query language (or data-oriented, uniform service APIs) to resolve client-specified "queries" and "mutations" against the schema.

We use GraphQL to dyn

QuadFlask

괄호가 유효한지 체크

My Solution

function validBraces(braces){
  var stack = [];
  return braces.split('').map(b=> {
    if ('({['.indexOf(b)>=0) {
      stack.push(b);
 return true;

Rich-Harris

Stuff I wish I'd known sooner about service workers

I recently had several days of extremely frustrating experiences with service workers. Here are a few things I've since learned which would have made my life much easier but which isn't particularly obvious from most of the blog posts and videos I've seen.

I'll add to this list over time – suggested additions welcome in the comments or via twitter.com/rich_harris.

Use Canary for development instead of Chrome stable

Chrome 51 has some pretty wild behaviour related to console.log in service workers. Canary doesn't, and it has a load of really good service worker related stuff in devtools.