JavaScript *

1. Нужен ли вам Express.js?
2. Устроит ли вас сохранение где-либо промежуточных данных, или вы хотите использовать потоковую передачу данных?
3. Если сохранение промежуточных данных вас устроит, предпочтёте ли вы, чтобы они хранились бы в памяти, или на жёстком диске?

Когда я был начинающим, я мог писать простые приложения на C# и C++. Долго игрался с консольными прогами, пощупал десктопные, и в какой-то момент захотел сделать сайт. Меня ждал большой сюрприз — чтобы делать сайты, одного сишарпа мало. Надо ещё знать жс, хтмл, цсс и прочую фронтовую хрень. Я потратил около недели на эти вещи, и понял — не мое. Я мог написать какой то код на джаваскрипт, но он не содержал типов, и я никак не мог взять в толк — как к этому вообще подходить. Это какое-то игрушечное программирование. Ну и забросил к чертям.

Уже потом, работе на третьей, меня перевели в отдел, где делали веб. Я подумывал уволиться, но мне объяснили — там тайпскрипт, тайпскрипт — это такой сишарп для браузера.

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

В оригинале эта заметка называется Hooks and Streams. Этот текст — не дословный перевод оригинала, часть оригинального текста изменена, часть пропущена. Иногда вместо термина Hooks используется слово ловушки или хуки, а вместо Streams — потоки. Тем не менее, я старался придерживаться стиля автора.

Hooks and Streams

Dan Abramov написал замечательный пост, о там как можно написать setInterval в декларативном стиле при помощи React Hooks.

Я полагаю, что Hooks хотя и не лишены недостатков, действительно интересное и технически перспективное изобретение. Если вы знаете the rules of hooks и понимаете, зачем хуки нужны, значит все в порядке. Но я надеюсь убедить вас, что существует более простое и лучшее решение.

Чтобы использовать Hooks, необходимо придерживаться четкого набора правил, так как, в конечном счете ловушки — это просто очень ловкий трюк. Хуки позволяют думать, что некоторое внешнее состояние доступно в области видимости вашей функции в момент ее вызова. Но это невозможно без дополнительной механики. В случае React эти механизмы вычисляют, какое состояние будет доступно некоторой функции в момент ее вызова, подсчитывая количество вызовов. Хотя реальный механизм сложнее, но в конечном итоге, это подсчет.

В прошлый раз, когда мы делали to-do на Alpine.js, меня очень сильно расстроило, что, хоть я и могу создавать вложенные компоненты, я не могу получать данные из родителя. Через какую-нибудь переменную, $parent, например.

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

Если вы подумали, что это не очень хорошо, то вы не правы. На самом деле, это ужасно.

Всё, расходимся? Нет. Я еще раз полистал документацию и вспомнил про магическое свойство $dispatch. Ну, конечно… однопоточная связь, проброс событий. Ну давайте попробуем. А потом еще переосмыслим всё с глобальным store.

Расцвет эпохи программируемых калькуляторов в нашей стране пришёлся на середину 80-х годов. Потом на смену относительно сытым и благополучным временам пришла эпоха бандитского капитализма, когда стране стало не до выпуска своей высокотехнологичной продукции бытового назначения, вот уже сменились поколения, но ностальгия по тем временам, когда мы бессонными ночами пытались сократить код программы хотя бы на пару байтов, чтобы уместить задуманную функцию, выискивали всё новые и новые недокументированные возможности, придумывая способы, как их можно использовать на практике, сочиняли целые циклы рассказов в качестве фона для наших игровых программ, не даёт забыть свой МК-61 со 105 байтами программной памяти. Поэтому хочу написать заметку о том, что собой представляли и как работали эти самые программируемые калькуляторы. Даже если эта тема сегодня периодически и поднимается, то не настолько часто, чтобы приесться уважаемому читателю, так что надеюсь поведать что-то новое.

Во Vuex есть одна популярная практика — не использовать mapState и mapMutations. Вообще. Вместо это мы сразу же при создании нового значения в store делаем для него геттер, а для каждой мутации – экшен.

Что-то наподобие:

export default new Vuex.Store({
  state: {
    // 1
    count: 0
  },
  getters: {
    // 1
    count: (state) => state.count
  },
  mutations: {
    // 2
    increment(state) {
      state.count++;
    }
  },
  actions: {
    // 2
    increment({ commit }) {
      commit('increment');
    }
  }
});

Холивара не избежать. Это уже доказала вот эта статья. Опять в интернете кто-то не прав, и я должен доказать почему. И я докажу.

"-Райан, мы тут концепцию CLI команд для Deno продумываем. Сколько флагов для secure runtime добавить?"
"-Да"
"-Райан, нам надо придумать символ языка, чтобы все понимали, что мы делаем что-то прям новое. Какое животное выберем?"
"-Динозавра"

p5.js — это библиотека для Javascript, созданная в 2014 году. Ее основная цель — стать окном в мир программирования для дизайнеров, художников, учителей и прочих представителей творческих профессий. Он поддерживает и анимацию, и схемы, легко переводится в веб-формат.