commonJS vs ES Module

for nodeJS, the server side is by default using commonJS for moduling.

//export data data.js
exports.staffs = [{
   name: "Bush",
   id: 1,
}, 
{
   name: "Forest",
   id: 2
}
];

//default export from module, default.js
module.exports = {name: "Gump"};

//then corresponding import
const { staffs, .... } = require('./data')
const anything = require('./default')


while client side is using ES modules:

//export
export const log = winston.createLogger({....});

//import 
import log from './logging/logger';

JS Frameworks

This crazy race has no winner at all since it is neverending. That’s it! Yesterday you were learning Backbone.js, jQuery, Knockout.js, Ember.js, then AngularJS and now ReactJS, Next.js, Vue.js, all Angular flavors. Today, up comes Ext JS and Aurelia, the new ones. And tomorrow another will come up. The framework array list is endless.

https://dev.to/blarzhernandez/why-you-should-learn-javascript-principles-first-not-the-hottest-frameworks-kb9

ES6 destructing and spread

http://www.typescriptlang.org/docs/handbook/variable-declarations.html#destructuring

destructuring is to auto map the source to the assigned variable, whether being array or object or tuple.


const [a,b,c] = ...

const {a,b,c} = …

const [a,b,c]= …

spread is to auto map any number of items in the array to a spread variable, vice versa. basically to repsent array as one (spread) variable.


const [a, ...b] = ...
const x = [a, ...b]

and in order to destruct array of objects

let o = [
{
a: "foo",
b: 12,
c: "bar"
},
{
a: "test",
b: 20,
c: "check"
}];

let [{a}] = o ====> “foo”

let [{a: a1},{a: a2}] = o ====> “foo”, test

Front End

1. redux flux

flux-528x174

Flux:
flux

redux
redux.png

2. jsx virtual dom
20160604082917065

3. reactJs redux
20180530214840982

basically similar to the flux flow(redux is one flux implementation), in (react) redux, component (user action, for example click a button) would trigger/generate an action, the action are being wrapped(like a container) within redux, it has a list registered listener (reducer) would act on the action (in redux, action is a noun, like a domain object, to tell the type of the action, and any additional parameters), reducer could 1) construct a new state (from existing + the new action), then store them in the store; 2) or with thunk, if could really take some action, for example, call a rest service, then generate a new state
after the new state, (which is always maintained/persisted in the store), the interested component could listen (observer) to these state (mapStateToProps), then update the component (display) correspondingly.

20180530223517561

20151210234529139

4. set up store, reducer, thunk

const store = createStore(
  reducer,
  applyMiddleware(thunk)
);

5. thunk
basically, “plain” redux, (supposed to be pure), only take in plain action (as a domain object, POJO); however, there are cases, it requires to run certain actions, (calling web service), with thunk, the “action” could be a function which then return a action(the real pojo).

export function getPosts_actionCreator_Thunk() {
  return function(dispatch) {
    return fetch("https://lwpro2.wordpress.com/super/posts")
      .then(response => response.json())
      .then(json => {
        dispatch({ type: "POST_LOADED", payload: json });
      });
  };
}

6. saga
sage is another way to implement what thunk’s. to iterate, Redux does not understand other types of action than a plain object.(for redux, actions is plain domain object).
Thunk is a middleware to extend redux, so that a function (thunk function) is put into the action creator, which could be run, and then return the action (domain object).
While saga is working in another approach. Saga is like an interceptor. So the original action creator is same, which simply return a plain domain action. However, saga can intercept all actions, if it’s saga’s interested actions (listener/observer pattern), it then intercept into its logic (the call of web service for example).

export function getPosts_actionCreator_original() {
  return { type: "POST_LOADED" };
}

export function loadPost_realFunction_original() {
    return fetch("https://lwpro2.wordpress.com/super/posts")
      .then(response => response.json());
}

import { takeEvery, call, put } from "redux-saga/effects";
export default function* interceptor_observer_Saga() {
  yield takeEvery("POST_LOADED", workerSaga);
}

function* workerSaga() {
  try {
    const payload = yield call(loadPost_realFunction_original);
    yield put({ type: "POST_LOADED", payload });
  } catch (e) {
    yield put({ type: "POST_LOAD_ERROR", payload: e });
  }
}

good summary for react redux thunk

source:
https://medium.com/@stowball/a-dummys-guide-to-redux-and-thunk-in-react-d8904a7005d3

  1. There is 1 global state object that manages the state for your entire application. In this example, it will behave identically to our initial component’s state. It is the single source of truth.
  2. The only way to modify the state is through emitting an action, which is an object that describes what should change. Action Creators are the functions that are dispatched to emit a change – all they do is return an action.
  3. When an action is dispatched, a Reducer is the function that actually changes the state appropriate to that action – or returns the existing state if the action is not applicable to that reducer.
  4. Reducers are “pure functions”. They should not have any side-effects nor mutate the state — they must return a modified copy.
  5. Individual reducers are combined into a single rootReducer to create the discrete properties of the state.
  6. The Store is the thing that brings it all together: it represents the state by using the rootReducer, any middleware (Thunk in our case), and allows you to actually dispatch actions.
  7. For using Redux in React, the <Provider /> component wraps the entire application and passes the storedown to all children.

https://codeburst.io/redux-a-crud-example-abb834d763c9