Разработчик широкого профиля
Привет, эта статья - "перевод документации и часто используемых примеров" для petite-vue + ещё немного приколов и одна интересная практика (с которой не всё так очевидно, как могло бы казаться).
Зачем нужен petite-vue?
Petite-vue это 6-ти килобайтное подмножество Vue, основной задачей которого, по словам Эвана, является Progressive Enchancement.
Всё началось с мема, который вы видите выше.
Сначала я посмеялся. А потом задумался: может ли быть так, что скриншот базы равноценен её снэпшоту?
Для этого у нас должно быть такое графическое представление базы, которое 1 к 1 отображает данные и структуру. Если сделать скриншот такого представления, из него можно восстановить базу.
Или... графическое представление и должно быть базой!
Мы искали сервис, в котором можно оценить качество городской среды, чтобы выбирать комфортные места для прогулок. Поиск не увенчался успехом, поэтому на примере Питера мы сделали карту гулябельности.
Часто информация, которая отображается пользователю и имеет свойства разметки, хранится в базе данных и сразу в формате HTML. Я уверен, что те, кто хоть раз создавал свой блог, Хабр или что-то подобное, скажут: «Да, было». Но что, если я предложу другой подход? Использовать JSON.
Давайте рассмотрим преимущества и недостатки такого хранения данных или, по крайней мере, попытаемся это сделать.
Во 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');
}
}
});Холивара не избежать. Это уже доказала вот эта статья. Опять в интернете кто-то не прав, и я должен доказать почему. И я докажу.
В статье [ссылка] было заявлено, что производительность Haskell кода превзошла код на С++. Что сразу вызвало интерес, т.к. и то и другое может генерироваться LLVM компилятором, значит либо Наskell может давать больше хинтов компилятору, либо что-то не так с С++ реализацией. Далее мы разберём, как череда случайностей в действиях автора привела к неправильным выводам, которые описываются таблицей ниже (под катом).