Новый взгляд на изучение и документирование исходного кода

О, это очень здорово! Хотелось бы поинтересоватся не думали ли вы подготовить представление пулл реквеста в подобной форме для code review. Бывает очень сложно понять что вообще происходит с кодом глобально особенно если на ревью большой кусок кода.
Основная проблема, во всяком случае случющейся у нас, это оценить как код соотностися с общей архетектурой проекта.

Организация reducer'а через стандартный класс

Я использую вот такую конструкцию чтоб избавится от бардака:
Акшен

import { LocalesApi } from '../api/locales.api';

class Actions {
  prefix = 'LOCALES_ACTIONS';
  REQUEST = `${this.prefix}_REQUEST`;
  SUCCESS = `${this.prefix}_SUCCESS`;
  ERROR = `${this.prefix}_ERROR`;
  CLEAR = `${this.prefix}_CLEAR`;

  request = () => ({
    type: this.REQUEST,
  })
  
  success = messages => ({
    type: this.SUCCESS,
    messages,
  })

  clear = () => ({
    type: this.CLEAR,
  })

  error = error => ({
    type: this.ERROR,
    error,
  })

  getByLocale = locale => async dispatch => {
    try {
      dispatch(this.request());
      const result = await LocalesApi.getByLocale(locale);
      dispatch(this.success(result));
    } catch (error) {
      dispatch(this.error(error.message));
    }
  }
}

export const LocalesActions = new Actions();й

Редюсер

import { LocalesActions } from '../actions/locales.actions';
import { LOCALES } from '../constants/locales.constants';

const initialState = {
  shouldInitialize: true,
  updating: false,
  locale: LOCALES.SUPPORTED[0],
  messages: {},
};

export default (state = initialState, action) => {
  switch (action.type) {
  case LocalesActions.REQUEST:
    return {
      ...state,
      shouldInitialize: false,
      updating: true,
    };
  case LocalesActions.SUCCESS:{ 
    const { messages } = action;
    return {
      ...state,
      updating: false,
      messages,
    };
  }
  case LocalesActions.ERROR:{ 
    const { error } = action;
    return {
      ...state,
      updating: false,
      error
    };
  }
  default:
    return state;
  }
};

Использование в контейнере

import { connect } from 'react-redux';

import { IntlProviderComponent } from './IntlProvider.component';
import { STORES } from '../constants/stores.constants';
import { LocalesActions } from '../actions/locales.actions';

const mapStateToProps = state => ({
  locales: state[STORES.LOCALES],
});

const mapDispatchToProps = dispatch => ({
  getMessages: locale => dispatch(LocalesActions.getByLocale(locale)),
});

export const IntlProvider = 
  connect(mapStateToProps, mapDispatchToProps)(IntlProviderComponent);

Почему ранний возврат из функций так важен?

Вот вот, проверку все равно делать, из за криворукости программистов, так? Ведь если параметры не проверять, то такая функция приведет к чудесам. Но вот скажем ваша функция вызывается миллион раз и лишь в одном случае я передал не правильные параметры. Получается я потратил ресурсы процессора просто так 999,999 раз и только чтоб отловить и залогировать всего одну ошибку. Я это к общей концепции современного программирования.

Почему ранний возврат из функций так важен?

Я этот подход уже давно использую, и вот читая статью я подумал, ведь это пессимистичный подход. С точки зрения производительности этот код видимо хуже того который сразу переходит к решению задачи. Ведь если подумать, то пессимистичный подход нужен только во время написания кода, а потом после отладки когда все работает, весь этот проверочный хлам будет мешать работе программы и влиять на производительность.

Запросы GraphQL без подключения к сети с помощью Redux Offline и Apollo

Спасибо, очень полезная статья.

Учимся мыслить в REM. Разговор об очевидном и о производительности труда в небольшой веб-студии

В адаптивном дизайне, лучше начинать с маленьких экранов и задавать адаптацию к большему разрешнию.
Давно уже думал о стандартизации размеров и как к этому дело подойти. Прдложенная схема полезна и для больших растущих проэктов. Так как именно в больших порэктах не каждая мелочь имеет свой дизайн.

К вопросу об истории и роли личности в ней (не по Плеханову)

Спасибо

«Байкал-T1»: знакомство с платой на первом в России 28-нм процессоре

MIL это не только температурный диапазон, но и EMI и там где надо измерения дифференциального шума и магнитнойсоставляющей, ну чтоб подслушивать тяжело было. И устойчивость к помхам там тоже есть к стати в шикарном диапазоне аж до 40гига (и больше по спецзаказам я тоже делал). Там где надо есть и EMP, но это требование я видел всего пару раз. Системой помехоустойчивость тоже конечно обеспечиваться должна. В конце концов MIL ето сложная процедура.

CodeceptJS — современные end2end тесты для NodeJS

Спасибо

CodeceptJS — современные end2end тесты для NodeJS

Мне не хватает в вашей статье обработки ошибок. Как это делается и какие есть возможности. Особенно синтакс, где именно и что завалилось. А то когда все хорошо у всех все хорошо :) Однако во время разработки, все хорошо с первого раза бывает редко.