Может у него было тяжелое начало, но сейчас, можно ли его считать полноценным?JS тьюринг полный язык и всегда им был. Тьюринг полнота означает, что на нем можно посчитать все что в принципе вычислимо.
Просто в нем даже импорт файла нормально нельзя сделать (даже в css он есть хоть и не полный)...Уже 5 лет как можно, в отличии, например, от C, где отдельные модули до сих пор нужно линковщиком собирать после компиляции. Так что, по Вашему C тоже не полноценный теперь?
Нету многих приколов, фишек и функций, хотя я понимаю что внедрять их поздно, и для браузера он создавался.Хотелось бы конкретики, каких таких "приколов" Вам не хватает? Вот тут ребята открыты к предложениям: https://github.com/tc39/ecma262/blob/master/CONTRI...
Почему AtomicDesign спасет вашу душу.
Некоторые считают, что этот подход слишком заморочен. Заставляет много думать о расположении элементов, а при усложнении - перемещать его в другие директории. Если спросить Родионова - найдется ещё несколько причин, почему не надо использовать Atomic Design. В этом посте я хочу рассказать об обратном: как использовать подход Брэда Фроста в React.
В самом начале необходимо понять - нужен ли вашей команде этот архитектурный дизайн. Достаточно ответить на следующие вопросы:
- сколько человек будут разрабатывать фронтенд?
- сколько команд будут использовать ваш код?
- сколько проектов используют один UI дизайн?
Если у вас один небольшой проект, в котором всего два фронтендера - вам не нужен AtomicDesign. Если в вашем проекте около 10 фронтендеров и намечается второй проект - нужно задуматься о внедрении AtomicDesign. Тем более если в вашей компании проекты используют общую библиотеку компонентов или планируется внедрение.
Многие задают мне один и тот же вопрос: "Куда положить компонент X?". Отвечаю сразу для всех компонентов: AtomicDesign - это подход, обеспечивающий вам архитектуру UI компонентов - не более. То есть контейнеры/коннекторы/роутеры вы можете класть в любую директорию, кроме ui. Я всегда рекомендую начать изучение с прочтения книги автора atomicdesign.bradfrost.com, но ниже немного опишу составные части.
Сразу следует понять, что компоненты AtomicDesign — это бизнес-сущности, это то, чем могут оперировать дизайнеры и разработчики вместе. Не надо включать сюда различные таймеры появления блоков или логику переключения вкладок. Пусть даже они у вас описаны в виде компонентов или HOC'ов.
Так почему это все спасает души? Чтобы понять ответ, обратимся к ещё одной теме фронтенда: типизированный javascript. Typescript/Flowtype придумали для наложения определенных ограничений на код, чтобы в дальнейшем его было проще поддерживать и читать. AtomicDesign накладывает ограничения на дизайнеров и фронтендеров, обязывая их общаться на одном языке бизнес-сущностей.
Но необходимо добавить несколько слов о поддержке библиотеки компонентов AtomicKit. В какой-то момент возникает проблема усложнения компонентов, и многие задаются вопросом: "Как же быть, неужели теперь нужно перемещать компонент из атомов в молекулы?" — Нет.
Перед стартом разработки необходимо тщательно проектировать набор компонентов и не менять его предназначения, пока он существует под таким названием. Если же вам необходимо усложнить компонент, добавить в него какие-то элементы - просто создайте ещё один компонент, который будет добавлять то, что вам нужно. Так вы не сломаете совместимость со всей библиотекой и реализуете необходимую вам фун
if(0 < 1){let div = document.createElement('div');
div.innerHTML="";if(reg.test(value) == false) {if(..){
var nextTab = resultNumberActiveTab + 1;
}
else if(...){
var nextTab = resultNumberActiveTab - 1;
}
console.log('Лол, кек, чебурек'); превратиться в var _0xac52=["\u041B\u043E\u043B\x2C\x20\u043A\u0435\u043A\x2C\x20\u0447\u0435\u0431\u0443\u0440\u0435\u043A","\x6C\x6F\x67"];console[_0xac52[1]](_0xac52[0])
const types = {
p: ['count', 'name', 'info', 'price'],
c: ['count', 'name', 'info', 'price'],
m: ['value', 'price'],
disk: ['count', 'name', 'price'],
radio: ['name', 'price'],
button: ['value', 'price'],
checkbox: ['name', 'price']
};
const values = {
name: optionName,
price: optionPrice,
value: optionValue,
count: optionCount,
info: optionChars
};
const result = types[type].reduce((acc, curr) => ({...acc, [curr]: values[curr]}), {});
if (type === 'checkbox') {
this.selectedOptions[type][`check${data.checkId}`] = result;
} else {
this.selectedOptions[type === 'disk' ? type + t.diskNumber : type] = result;
}
Должен ли UX/UI дизайнер знать компоненты таких фреймворков как React и Vue
подготавливать макет прямо на React, но без логики
не зная можно ли вообще реализовать такой календарь
но наверное какие-то основы, работу с NPM, CSS/SASS препроцессоры он должен знать?
