Двач.hk не отвечает.
Вы видите копию треда, сохраненную 13 мая 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Вы видите копию треда, сохраненную 13 мая 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
56 Кб, 1050x1050Предыдущий тред: >>1944376 (OP)
Больше пары строк кода в посте или на скриншоте ведут в ад.
Для программирования на HTML https://codesandbox.io
Для Node.js с консолькой https://repl.it/languages/nodejs
Если рассчитываешь получить дельный ответ, сформулируй правильно вопрос: «что я хочу получить, что я для этого делаю, что я вместо этого получаю». Если когда самостоятельно найдёшь решение — поделись в треде, мы за тебя переживаем.
Документация - https://developer.mozilla.org
Руководство для вката - https://github.com/acilsd/wrk-fet#javascript
Старая паста, частично устарела - https://pastebin.com/9yRADC0s
Больше пары строк кода в посте или на скриншоте ведут в ад.
Для программирования на HTML https://codesandbox.io
Для Node.js с консолькой https://repl.it/languages/nodejs
Если рассчитываешь получить дельный ответ, сформулируй правильно вопрос: «что я хочу получить, что я для этого делаю, что я вместо этого получаю». Если когда самостоятельно найдёшь решение — поделись в треде, мы за тебя переживаем.
Документация - https://developer.mozilla.org
Руководство для вката - https://github.com/acilsd/wrk-fet#javascript
Старая паста, частично устарела - https://pastebin.com/9yRADC0s
первый нах
>>0916
На битриксе
На битриксе
>>0916
ng ngrx
ng ngrx
>>0886 (OP)
Как создавать синглтоны? Так:
const singleton = {
поле: значение,
метод: function() {}
}
Или так:
class Singleton {
поле = значение;
метод() {}
}
const singleton = new Singleton();
Как правильнее?
Как создавать синглтоны? Так:
const singleton = {
поле: значение,
метод: function() {}
}
Или так:
class Singleton {
поле = значение;
метод() {}
}
const singleton = new Singleton();
Как правильнее?
>>0916
1с
1с
>>0923
Как хочешь, но это не синглтон ни в одном из вариантов и к паттерну отношения не имеет.
Как хочешь, но это не синглтон ни в одном из вариантов и к паттерну отношения не имеет.
>>0916
vue3/nuxtjs
vue3/nuxtjs
>>0945
А как тогда синглтон делается? Я думал, что синглтон - это просто единственный экземпляр какого-то класса. По крайней мере так в примерах Википедии или где-то ещё видел.
А как тогда синглтон делается? Я думал, что синглтон - это просто единственный экземпляр какого-то класса. По крайней мере так в примерах Википедии или где-то ещё видел.
>>0945
>>0972
А, перечитал Вики, короче синглтон должен запрещать создание новых экземпляров, возвращая самого себя в случае попытки пересоздания. Ну, это всё мне не важно, меня интересовал только синтаксис.
>>0940
Мне синтаксис тут не нравится, через class удобнее. Тем более что можно использовать наследование (extends) и есть конструктор...
>>0972
А, перечитал Вики, короче синглтон должен запрещать создание новых экземпляров, возвращая самого себя в случае попытки пересоздания. Ну, это всё мне не важно, меня интересовал только синтаксис.
>>0940
Мне синтаксис тут не нравится, через class удобнее. Тем более что можно использовать наследование (extends) и есть конструктор...
>>0978
В зависимости от ситуации. Если у тебя есть набор логически связанных действий и данных, служащих одной конкретной цели, то удобнее и красивее будет объявить хорошо названный класс с продуманным интерфейсом, чем дрочиться с обычным объектом-хэшмапой. Если же ты просто хочешь запихать что-то в одно место, мержить это что-то с другим чем-то, убирать оттуда куски и т.д, то удобнее будет просто сделать объект, чем дрочиться с конструкторами и this.
В зависимости от ситуации. Если у тебя есть набор логически связанных действий и данных, служащих одной конкретной цели, то удобнее и красивее будет объявить хорошо названный класс с продуманным интерфейсом, чем дрочиться с обычным объектом-хэшмапой. Если же ты просто хочешь запихать что-то в одно место, мержить это что-то с другим чем-то, убирать оттуда куски и т.д, то удобнее будет просто сделать объект, чем дрочиться с конструкторами и this.
>>0979
Эээ... я уже обдрочился этим this, есть способ обращаться к полям/методам класса без обязательного указания this? В других ЯП я никогда не встречал такого частого обращения к this/self (пытаясь убрать this, консоль срёт сообщениями "ололо не найдено").
>дрочиться с this
Эээ... я уже обдрочился этим this, есть способ обращаться к полям/методам класса без обязательного указания this? В других ЯП я никогда не встречал такого частого обращения к this/self (пытаясь убрать this, консоль срёт сообщениями "ололо не найдено").
>>0986
В php погляди на любой класс, он на половину состоит из $this-> или python, там тоже кругом одни self в классах. В других языках просто поведение this более предсказуемо, чем в js
>не встречал такого частого обращения к this/self
В php погляди на любой класс, он на половину состоит из $this-> или python, там тоже кругом одни self в классах. В других языках просто поведение this более предсказуемо, чем в js
>>0987
Ладно.
А локально сокращать код как-нибудь можно?
Вот у меня часто бывает что-то вроде такого:
В некоторых языках есть оператор with, можно ли сделать так:
? А то конструкции уж больно монструозные получаются.
Предполагаю, можно сделать так:
Т.к. parent - объект, то в p копируется только ссылка.
Но не сильно ли такой способ "сокращения" загружает JS-машину?
Ладно.
А локально сокращать код как-нибудь можно?
Вот у меня часто бывает что-то вроде такого:
>for (let i in this.parent.items)
>if (this.parent.items[ i ] !== this)
>this.parent.items[ i ].close();
В некоторых языках есть оператор with, можно ли сделать так:
>with (this.parent)
>for (let i in items)
>if (items[ i ] !== this)
>items[ i ].close();
? А то конструкции уж больно монструозные получаются.
Предполагаю, можно сделать так:
>const p = this.parent;
>for (let i in p.items)
>if (p.items[ i ] !== this)
>p.items[ i ].close();
Т.к. parent - объект, то в p копируется только ссылка.
Но не сильно ли такой способ "сокращения" загружает JS-машину?
>>1000
Ты рофлишь? Если только у тебя на 1 миллион таких объектов, вообще нет смысла делать эти микрооптимизации. То же касается циклов, нахуя тебе for если есть forEach, map, reduce.
>Но не сильно ли такой способ "сокращения" загружает JS-машину?
Ты рофлишь? Если только у тебя на 1 миллион таких объектов, вообще нет смысла делать эти микрооптимизации. То же касается циклов, нахуя тебе for если есть forEach, map, reduce.
>>1000
this.parents.items
.filter(item => item !== this)
.forEach(item => item.close());
>for (let i in this.parent.items)
>if (this.parent.items[ i ] !== this)
>this.parent.items[ i ].close();
this.parents.items
.filter(item => item !== this)
.forEach(item => item.close());
>>1015
const closeItem = item => item.close();
const closeItems = pipe(
reject(equals(this)),
forEach(closeIte )
)
closeItems(this.parent.items);
Пофиксил маньку
мимо ramda господин
const closeItem = item => item.close();
const closeItems = pipe(
reject(equals(this)),
forEach(closeIte )
)
closeItems(this.parent.items);
Пофиксил маньку
мимо ramda господин
>>1014
Я знаю только что интерпретаторы медленные и сайты с обилием JS на моём компе/телефонах часто тормозят, NoScript их ускоряет. Не хочу идти по чужим граблям и нагружать интерпретатор мусором.
Слышал о таком, никогда не использовал, надо погуглить.
>>1015
Я привык всё вручную делать, императивно. ФП вообще боюсь, тёмный лес. А это делается только для удобства программиста или filter() и forEach() будут быстрее одного for с if'ми? Просто как по мне, for и if читабельнее, ближе к тому, как я представляю решение задачи. Я читаю это примерно так: "для каждого i в items, если items не этот объект, то закрыть его". А твоя запись хоть и понятна, но не читается, что-то вроде "фильтровать items, убрав этот объект, затем каждый закрыть"? Мастера Йоды получается код)
>>1021
Это вообще непонятно, это ФП или что-то новое? Как гуглить?
>>1025
Согласен.
Я знаю только что интерпретаторы медленные и сайты с обилием JS на моём компе/телефонах часто тормозят, NoScript их ускоряет. Не хочу идти по чужим граблям и нагружать интерпретатор мусором.
>если есть forEach, map, reduce
Слышал о таком, никогда не использовал, надо погуглить.
>>1015
Я привык всё вручную делать, императивно. ФП вообще боюсь, тёмный лес. А это делается только для удобства программиста или filter() и forEach() будут быстрее одного for с if'ми? Просто как по мне, for и if читабельнее, ближе к тому, как я представляю решение задачи. Я читаю это примерно так: "для каждого i в items, если items не этот объект, то закрыть его". А твоя запись хоть и понятна, но не читается, что-то вроде "фильтровать items, убрав этот объект, затем каждый закрыть"? Мастера Йоды получается код)
>>1021
Это вообще непонятно, это ФП или что-то новое? Как гуглить?
>>1025
Согласен.
38 Кб, 825x501>>1037
Это как говорить что не хочу портить океан и ссать в него. Нужно нагрузить очень много джаваскрипта в память, чтобы вызвать тормоза хоть на пару миллисекунд на уровне языка. 99% тормозов в веб-приложениях из-за DOM, то есть обновления самой страницы и ререндеринга, а не из-за вычислений переменных в JS'е. В примере выше
Мы делаем 2 цикла, вместо одного, как в императивном подходе, но это не имеет никакого значения пока у тебя в массивах меньше 10к элементов.
>>1037
Ну тогда тебе будет тяжело найти работу, т.к. на фронте сейчас ФП подходы более приветствуются, т.к. читаемость и расширяемость кода это одна из главных характеристик хорошего кода, а не пикосекунды исполнения. Вызывание функций намного более читабельнее и реюзабельней, чем портянки из if и for. Конечно, в твоем примере разницы никакой нет, но добавь туда еще 1-2 проверки и еще одно действие которое надо будет выполнить над items (а это зачастую и нужно сделать в реальных проектах рано или поздно) и ты уже получаешь лапшу:
Это нечитабельный и очень императивный код в своей основе. Конечно, он кажется читаемым потому что ты написал его 5 минут назад и ТЫ написал его. Но для других программистов нужно прикладывать когнитивные усилия, чтобы осмыслить цикла, доступа к объекту, проверке !== и вызове метода. В подобном коде легко сделать ошибку.
В функциональном подходе из-за того что код разделен на мелкие, но хорошо делающие свои работу функции, код очень легко расширять, менять и читать. Циклы, проверки и другие частые операции уже вынесены в функции и тебе не нужно переживать что кто-то где-то скипнул часть цикла или поменял элемент внутри массива по ошибке.
Но, безусловно, есть некий порог входа и в самом начале изучения ФП код кажется более СЛОЖНО читаемым. Но через некоторое время практики ты будешь удивляться, как теперь весь код для тебя это процесс вычислений значений и будет сложно писать в императивном стиле (потому что на него нужно тратить больше усилий).
В любом случае, не обязательно нырять в функциональный подход на 100, более того зачастую это невозможно, потому что код над которым ты работаешь это легаси от прошлых разрабов или команда в которой ты работаешь слабая по скиллу и может только хреначить портянки на jQuery сам начинал с подобного.
В твоем случае forEach и filter предпочитаемы итеративному обходу и проверке, просто небольшой совет.
>Не хочу идти по чужим граблям и нагружать интерпретатор мусором.
Это как говорить что не хочу портить океан и ссать в него. Нужно нагрузить очень много джаваскрипта в память, чтобы вызвать тормоза хоть на пару миллисекунд на уровне языка. 99% тормозов в веб-приложениях из-за DOM, то есть обновления самой страницы и ререндеринга, а не из-за вычислений переменных в JS'е. В примере выше
>this.parents.items
>.filter(item => item !== this)
>.forEach(item => item.close());
Мы делаем 2 цикла, вместо одного, как в императивном подходе, но это не имеет никакого значения пока у тебя в массивах меньше 10к элементов.
>>1037
>Я привык всё вручную делать, императивно. ФП вообще боюсь, тёмный лес.
Ну тогда тебе будет тяжело найти работу, т.к. на фронте сейчас ФП подходы более приветствуются, т.к. читаемость и расширяемость кода это одна из главных характеристик хорошего кода, а не пикосекунды исполнения. Вызывание функций намного более читабельнее и реюзабельней, чем портянки из if и for. Конечно, в твоем примере разницы никакой нет, но добавь туда еще 1-2 проверки и еще одно действие которое надо будет выполнить над items (а это зачастую и нужно сделать в реальных проектах рано или поздно) и ты уже получаешь лапшу:
>for (let i in this.parent.items)
>if (this.parent.items[ i ] !== this && this.parent.items.isOpened)
>this.parent.items[ i ].close();
>if (this.parent.items.hasSomething)
>this.parent.items.doSomething();
Это нечитабельный и очень императивный код в своей основе. Конечно, он кажется читаемым потому что ты написал его 5 минут назад и ТЫ написал его. Но для других программистов нужно прикладывать когнитивные усилия, чтобы осмыслить цикла, доступа к объекту, проверке !== и вызове метода. В подобном коде легко сделать ошибку.
В функциональном подходе из-за того что код разделен на мелкие, но хорошо делающие свои работу функции, код очень легко расширять, менять и читать. Циклы, проверки и другие частые операции уже вынесены в функции и тебе не нужно переживать что кто-то где-то скипнул часть цикла или поменял элемент внутри массива по ошибке.
Но, безусловно, есть некий порог входа и в самом начале изучения ФП код кажется более СЛОЖНО читаемым. Но через некоторое время практики ты будешь удивляться, как теперь весь код для тебя это процесс вычислений значений и будет сложно писать в императивном стиле (потому что на него нужно тратить больше усилий).
В любом случае, не обязательно нырять в функциональный подход на 100, более того зачастую это невозможно, потому что код над которым ты работаешь это легаси от прошлых разрабов или команда в которой ты работаешь слабая по скиллу и может только хреначить портянки на jQuery сам начинал с подобного.
В твоем случае forEach и filter предпочитаемы итеративному обходу и проверке, просто небольшой совет.
38 Кб, 825x501>>1037
Это как говорить что не хочу портить океан и ссать в него. Нужно нагрузить очень много джаваскрипта в память, чтобы вызвать тормоза хоть на пару миллисекунд на уровне языка. 99% тормозов в веб-приложениях из-за DOM, то есть обновления самой страницы и ререндеринга, а не из-за вычислений переменных в JS'е. В примере выше
Мы делаем 2 цикла, вместо одного, как в императивном подходе, но это не имеет никакого значения пока у тебя в массивах меньше 10к элементов.
>>1037
Ну тогда тебе будет тяжело найти работу, т.к. на фронте сейчас ФП подходы более приветствуются, т.к. читаемость и расширяемость кода это одна из главных характеристик хорошего кода, а не пикосекунды исполнения. Вызывание функций намного более читабельнее и реюзабельней, чем портянки из if и for. Конечно, в твоем примере разницы никакой нет, но добавь туда еще 1-2 проверки и еще одно действие которое надо будет выполнить над items (а это зачастую и нужно сделать в реальных проектах рано или поздно) и ты уже получаешь лапшу:
Это нечитабельный и очень императивный код в своей основе. Конечно, он кажется читаемым потому что ты написал его 5 минут назад и ТЫ написал его. Но для других программистов нужно прикладывать когнитивные усилия, чтобы осмыслить цикла, доступа к объекту, проверке !== и вызове метода. В подобном коде легко сделать ошибку.
В функциональном подходе из-за того что код разделен на мелкие, но хорошо делающие свои работу функции, код очень легко расширять, менять и читать. Циклы, проверки и другие частые операции уже вынесены в функции и тебе не нужно переживать что кто-то где-то скипнул часть цикла или поменял элемент внутри массива по ошибке.
Но, безусловно, есть некий порог входа и в самом начале изучения ФП код кажется более СЛОЖНО читаемым. Но через некоторое время практики ты будешь удивляться, как теперь весь код для тебя это процесс вычислений значений и будет сложно писать в императивном стиле (потому что на него нужно тратить больше усилий).
В любом случае, не обязательно нырять в функциональный подход на 100, более того зачастую это невозможно, потому что код над которым ты работаешь это легаси от прошлых разрабов или команда в которой ты работаешь слабая по скиллу и может только хреначить портянки на jQuery сам начинал с подобного.
В твоем случае forEach и filter предпочитаемы итеративному обходу и проверке, просто небольшой совет.
>Не хочу идти по чужим граблям и нагружать интерпретатор мусором.
Это как говорить что не хочу портить океан и ссать в него. Нужно нагрузить очень много джаваскрипта в память, чтобы вызвать тормоза хоть на пару миллисекунд на уровне языка. 99% тормозов в веб-приложениях из-за DOM, то есть обновления самой страницы и ререндеринга, а не из-за вычислений переменных в JS'е. В примере выше
>this.parents.items
>.filter(item => item !== this)
>.forEach(item => item.close());
Мы делаем 2 цикла, вместо одного, как в императивном подходе, но это не имеет никакого значения пока у тебя в массивах меньше 10к элементов.
>>1037
>Я привык всё вручную делать, императивно. ФП вообще боюсь, тёмный лес.
Ну тогда тебе будет тяжело найти работу, т.к. на фронте сейчас ФП подходы более приветствуются, т.к. читаемость и расширяемость кода это одна из главных характеристик хорошего кода, а не пикосекунды исполнения. Вызывание функций намного более читабельнее и реюзабельней, чем портянки из if и for. Конечно, в твоем примере разницы никакой нет, но добавь туда еще 1-2 проверки и еще одно действие которое надо будет выполнить над items (а это зачастую и нужно сделать в реальных проектах рано или поздно) и ты уже получаешь лапшу:
>for (let i in this.parent.items)
>if (this.parent.items[ i ] !== this && this.parent.items.isOpened)
>this.parent.items[ i ].close();
>if (this.parent.items.hasSomething)
>this.parent.items.doSomething();
Это нечитабельный и очень императивный код в своей основе. Конечно, он кажется читаемым потому что ты написал его 5 минут назад и ТЫ написал его. Но для других программистов нужно прикладывать когнитивные усилия, чтобы осмыслить цикла, доступа к объекту, проверке !== и вызове метода. В подобном коде легко сделать ошибку.
В функциональном подходе из-за того что код разделен на мелкие, но хорошо делающие свои работу функции, код очень легко расширять, менять и читать. Циклы, проверки и другие частые операции уже вынесены в функции и тебе не нужно переживать что кто-то где-то скипнул часть цикла или поменял элемент внутри массива по ошибке.
Но, безусловно, есть некий порог входа и в самом начале изучения ФП код кажется более СЛОЖНО читаемым. Но через некоторое время практики ты будешь удивляться, как теперь весь код для тебя это процесс вычислений значений и будет сложно писать в императивном стиле (потому что на него нужно тратить больше усилий).
В любом случае, не обязательно нырять в функциональный подход на 100, более того зачастую это невозможно, потому что код над которым ты работаешь это легаси от прошлых разрабов или команда в которой ты работаешь слабая по скиллу и может только хреначить портянки на jQuery сам начинал с подобного.
В твоем случае forEach и filter предпочитаемы итеративному обходу и проверке, просто небольшой совет.
>>1076
А чем по-твоему школьники отличаются о не-школьников? Хочешь чтобы коров с собачками считали и картинки красивые? Бери обычные курсы и не выебывайся.
А чем по-твоему школьники отличаются о не-школьников? Хочешь чтобы коров с собачками считали и картинки красивые? Бери обычные курсы и не выебывайся.
>>0886 (OP)
Мде, писал тут пасту про STMы, а модер взял и потёр тред, где я всё это писал, ну ладно.
Мде, писал тут пасту про STMы, а модер взял и потёр тред, где я всё это писал, ну ладно.
>>1174
Вот и я про то.
Там было про MobX & MST, recoil, overmind, xstate.
Суть: ничего более естественного чем redux-saga ещё не придумали.
Вот и я про то.
Там было про MobX & MST, recoil, overmind, xstate.
Суть: ничего более естественного чем redux-saga ещё не придумали.
>>1176
Зачем? Зачем вы по воле собственной тащите эту ебанину в свои проекты? Я в целом про редакс.
>redux-saga
Зачем? Зачем вы по воле собственной тащите эту ебанину в свои проекты? Я в целом про редакс.
Нормальная ли это практика делать один эвент листенер на ресайз окна в сторе, и потом передавать его во все необходимые компоненты? Есть много разных компонентов, и в каждом из них отдельно вешается эвентлистенер, и потом применяются стили в зависимости от размеров. Если я просто в сторе этот эвентлистенер повешу это нормально? Какие могут быть недостатки у такого подхода?
>>1207
Окей, переформулирую.
Хорошо, представь себе список, где каждый шаг описан в декларативном стиле. Вот это то, что позволяет тебе саги.
>>1202
Я сравнил разные стейт-менеджеры и не нашёл ничего такого, что побудило бы меня начать юзать другой STM.
redux-saga - до сих пор лучшее, что есть для асинк флоу логики.
Окей, переформулирую.
Хорошо, представь себе список, где каждый шаг описан в декларативном стиле. Вот это то, что позволяет тебе саги.
>>1202
Я сравнил разные стейт-менеджеры и не нашёл ничего такого, что побудило бы меня начать юзать другой STM.
redux-saga - до сих пор лучшее, что есть для асинк флоу логики.
>>1229
Это не отвечает на вопрос о естественности.
С чего ты решил, что декларативно естестевннее императивного?
Сравни.
1. Обуйся.
2. Надень шапку.
И
1. Ты обут.
2. Шапка надета.
С тобой в детстве мама в каком формате разговаривала, что для тебя второй более естественнен?
>переформулирую
Это не отвечает на вопрос о естественности.
С чего ты решил, что декларативно естестевннее императивного?
Сравни.
1. Обуйся.
2. Надень шапку.
И
1. Ты обут.
2. Шапка надета.
С тобой в детстве мама в каком формате разговаривала, что для тебя второй более естественнен?
>>1233
То что ты выше перечислил выглядит естественным.
Неестественным это становится, когда ты смотришь на какой-то код и не понимаешь, что он означает, потому что он написан таким образом, что зависит от многих других частей.
Задача программиста - выразить сложный флоу естественным образом, чтобы он читался как рецепт, а не мешанина хуй знает чего.
То что ты выше перечислил выглядит естественным.
Неестественным это становится, когда ты смотришь на какой-то код и не понимаешь, что он означает, потому что он написан таким образом, что зависит от многих других частей.
Задача программиста - выразить сложный флоу естественным образом, чтобы он читался как рецепт, а не мешанина хуй знает чего.
>>1251
Декларативность не описывает флоу, она описывает реультат. Флоу описывает императивность.
Декларативность не описывает флоу, она описывает реультат. Флоу описывает императивность.
>>1254
Скажем, императивность имеет разную степень абстрагирования.
Задача программиста - выразить сложный флоу таким образом, чтобы это всё было в читабельном для человека виде, а не только для машины.
const makeUsername = word |> stripSpace |> rejectNonalphabetic |> validateLength
Скажем, императивность имеет разную степень абстрагирования.
Задача программиста - выразить сложный флоу таким образом, чтобы это всё было в читабельном для человека виде, а не только для машины.
const makeUsername = word |> stripSpace |> rejectNonalphabetic |> validateLength
171 Кб, 982x1472Охладите естественное траханье в этом треде на минутку и задекларируйте тут ваше видение идеальной модульной архитектуры на жс. И как бы вы распиливали бы на модули огромное монолитное приложение, которое становится уже сложно поддерживать и которое собирается целую вечность.
>>1261
ты дебил блядь
ты дебил блядь
>>1206
Так. У меня другая проблема. Я повесил эвент листенер. И он нормально передает значение в компоненты при ресайзе. Но вот в чем дело, мне нужно как-то считать initial размер окна еще до любого ресайза. Я бы мог просто присвоить начальное значение из текущего размера окна winWidth = windows.innerWidth. Но вот очевидно что ssr такое не понравится. И я не знаю как обратно к серверу передать значение из клиента. Чтобы на сервере тоже размер окна брался сразу с клиента, потому что если использовать всякие юзэффекты, то стили будут прыгать, потому что изначально значение будет браться из стора. В какую сторону гуглить?
Так. У меня другая проблема. Я повесил эвент листенер. И он нормально передает значение в компоненты при ресайзе. Но вот в чем дело, мне нужно как-то считать initial размер окна еще до любого ресайза. Я бы мог просто присвоить начальное значение из текущего размера окна winWidth = windows.innerWidth. Но вот очевидно что ssr такое не понравится. И я не знаю как обратно к серверу передать значение из клиента. Чтобы на сервере тоже размер окна брался сразу с клиента, потому что если использовать всякие юзэффекты, то стили будут прыгать, потому что изначально значение будет браться из стора. В какую сторону гуглить?
>>1277
Один раз об такое уже споткнулся. Оказалось, что крайне неудобно бегать с репозитория туда-сюда, когда фактическая зависимость между кодом в разных репах осталась высокая. Многие изменения требовали вносить правки сразу в несколько репов, что оказалось просто болью.
Это, впрочем, не проблема разделения на отдельные репозитории, а проблема, что огромный монолит распилить красиво, что бы потом все было удобно и без зависимости друг от друга, действительно сложно. В итоге тот проект вернулся в один реп, но был поделен на несколько кусков которые могли собираться независимо друг от друга.
Один раз об такое уже споткнулся. Оказалось, что крайне неудобно бегать с репозитория туда-сюда, когда фактическая зависимость между кодом в разных репах осталась высокая. Многие изменения требовали вносить правки сразу в несколько репов, что оказалось просто болью.
Это, впрочем, не проблема разделения на отдельные репозитории, а проблема, что огромный монолит распилить красиво, что бы потом все было удобно и без зависимости друг от друга, действительно сложно. В итоге тот проект вернулся в один реп, но был поделен на несколько кусков которые могли собираться независимо друг от друга.
>>1277
>>1285
Бля, парни, я про репо в контексте паттерна ( https://developer.android.com/jetpack/guide#connect-viewmodel-repository ), а не структуры проекта.
>>1285
Бля, парни, я про репо в контексте паттерна ( https://developer.android.com/jetpack/guide#connect-viewmodel-repository ), а не структуры проекта.
>>1290
Кек, ясно. Протупил.
Ладно, а что вы делает (идеально в контексте ts, но вообще не столь важно) с огромными классами в js? Extend? Mixins? Subclasses? Можно еще часть логики выделить во внешнею и пихать как DI.
Кек, ясно. Протупил.
Ладно, а что вы делает (идеально в контексте ts, но вообще не столь важно) с огромными классами в js? Extend? Mixins? Subclasses? Можно еще часть логики выделить во внешнею и пихать как DI.
>>1307
У нас DI на ридерах, сорри, не подскажу, что делать с большими классами, кроме очевидных советов.
У нас DI на ридерах, сорри, не подскажу, что делать с большими классами, кроме очевидных советов.
useEffect вызывается как только компонент отрендерился, но в нем же делают запросы к api, без запроса к api нахуй рендерить компонент если в нем еще нет нужных данных?
>>1335
чтобы не показывать пустую страницу, пока у тебя запрос не зарезолвился
чтобы не показывать пустую страницу, пока у тебя запрос не зарезолвился
>>1056
Кстати, как это правильно делать, если нужно вывести (div.append()) сразу много элементов?
Я обычно программирую как привык. И если привыкну к неоптимальному подходу, буду использовать его всегда, а потом тратить время на поиск узких мест. Зачем писать неоптимально, если более быстрый вариант пишется нетрудно? Я же не ассемблерные вставки пишу. А то здесь два цикла, там два цикла, так и накопится снежный ком лишних действий, а потом поди разберись в нём.
Так а я и не ищу) Для работы нужно иметь кучу других качеств и навыков, кроме программирования на уровне любителя. Я пишу программы для своих задач и удовольствия, остальное меня не интересует.
Знаю и понимаю. Но функции - это не уникальная черта ФП. Портянку из for и if я дроблю на субфункции, когда становится непонятно, что происходит. И эти субфункции я могу назвать в соответствии с контекстом, не полагаясь на стандартное название из какой-то библиотеки.
Лапша - это когда в коде много связей между случайными участками, т.е. из многих мест идут обращения во многие места, из-за чего становится трудно понять, что на что влияет и как оно вообще работает. А длинный код не обязательно "лапша", его обычно можно разделить на отдельные функции, передавая результат от одной к другой.
Твой пример можно переписать читабельнее, но, во-первых, данными управлять должен сам элемент. Если данные нужно сохранить перед закрытием, то проверка и сохранение данных происходят в методе item.close(), а не в item.closeSiblings(), следовательно код упрощается.
Во-вторых, проверка открытости элемента производится опять же самим элементом в методе item.close(), потому что наше дело предложить ему закрыться, а ему решать, может ли он закрыться.
Тогда будет только:
А вот уже в close() будет что-то вроде:
В saveData():
...ну, ладно, один .forEach тут бы не повредил, типа
Но смысла в .filter() здесь не вижу. Фильтр был бы полезен, если бы мы потом с этим списком что-то сложное делали, т.е. сохраняли отдельно и редактировали...
А вообще я не пойму, в чём тут ФП? Это же императивные команды "сделай это", даже порядок соблюдается слева направо, а не наоборот. Против такого кода ничего не имею, пока названия функций имеют смысл (forEach = для каждого, в данном контексте нормально). Но большая часть виденного мной функционального кода читаемых имён не содержит (зато куча спецсимволов).
Так и мой код тоже поделён на мелкие (по возможности) функции. Только у моих функций название есть и соответствует контексту/области видимости, а в функциональщине названий либо нет, либо они из спецсимволов и скобок.
Тот же цикл forEach, по-хорошему, часть императивного кода:
Вот это максимально читаемый код, читается как русский язык:
А если оборачивать в скобки и спецсимволы, получается нечитабельная фигня.
Вообще я фанат алгол-подобных языков, хочу обмазываться длинными словами из букв и не хочу контактировать со спецсимволами. Увы, в вебе есть только JS, но я уже не против, тут не так много спецсимволов, как во всяких сях.
>из-за DOM, то есть обновления самой страницы и ререндеринга
Кстати, как это правильно делать, если нужно вывести (div.append()) сразу много элементов?
>это не имеет никакого значения пока у тебя в массивах меньше 10к элементов
Я обычно программирую как привык. И если привыкну к неоптимальному подходу, буду использовать его всегда, а потом тратить время на поиск узких мест. Зачем писать неоптимально, если более быстрый вариант пишется нетрудно? Я же не ассемблерные вставки пишу. А то здесь два цикла, там два цикла, так и накопится снежный ком лишних действий, а потом поди разберись в нём.
>найти работу
Так а я и не ищу) Для работы нужно иметь кучу других качеств и навыков, кроме программирования на уровне любителя. Я пишу программы для своих задач и удовольствия, остальное меня не интересует.
>читаемость и расширяемость
Знаю и понимаю. Но функции - это не уникальная черта ФП. Портянку из for и if я дроблю на субфункции, когда становится непонятно, что происходит. И эти субфункции я могу назвать в соответствии с контекстом, не полагаясь на стандартное название из какой-то библиотеки.
>получаешь лапшу
Лапша - это когда в коде много связей между случайными участками, т.е. из многих мест идут обращения во многие места, из-за чего становится трудно понять, что на что влияет и как оно вообще работает. А длинный код не обязательно "лапша", его обычно можно разделить на отдельные функции, передавая результат от одной к другой.
Твой пример можно переписать читабельнее, но, во-первых, данными управлять должен сам элемент. Если данные нужно сохранить перед закрытием, то проверка и сохранение данных происходят в методе item.close(), а не в item.closeSiblings(), следовательно код упрощается.
Во-вторых, проверка открытости элемента производится опять же самим элементом в методе item.close(), потому что наше дело предложить ему закрыться, а ему решать, может ли он закрыться.
Тогда будет только:
>for (let i in this.parent.items) if (this.parent.items[ i ] !== this) this.parent.items[ i ].close();
А вот уже в close() будет что-то вроде:
>if (this.opened) { this.saveData(); this.toogle(); }
В saveData():
>if (this.needToSave) { ... }
...ну, ладно, один .forEach тут бы не повредил, типа
>this.parent.items.forEach(item => { if (item !== this) item.close() });
Но смысла в .filter() здесь не вижу. Фильтр был бы полезен, если бы мы потом с этим списком что-то сложное делали, т.е. сохраняли отдельно и редактировали...
А вообще я не пойму, в чём тут ФП? Это же императивные команды "сделай это", даже порядок соблюдается слева направо, а не наоборот. Против такого кода ничего не имею, пока названия функций имеют смысл (forEach = для каждого, в данном контексте нормально). Но большая часть виденного мной функционального кода читаемых имён не содержит (зато куча спецсимволов).
>код поделён на мелкие функции
Так и мой код тоже поделён на мелкие (по возможности) функции. Только у моих функций название есть и соответствует контексту/области видимости, а в функциональщине названий либо нет, либо они из спецсимволов и скобок.
Тот же цикл forEach, по-хорошему, часть императивного кода:
>for item in items do if item <> self then item.close();
Вот это максимально читаемый код, читается как русский язык:
>для каждого итема в итемс проверяем что это не мы и закрываем соседей
А если оборачивать в скобки и спецсимволы, получается нечитабельная фигня.
Вообще я фанат алгол-подобных языков, хочу обмазываться длинными словами из букв и не хочу контактировать со спецсимволами. Увы, в вебе есть только JS, но я уже не против, тут не так много спецсимволов, как во всяких сях.
>>1056
Кстати, как это правильно делать, если нужно вывести (div.append()) сразу много элементов?
Я обычно программирую как привык. И если привыкну к неоптимальному подходу, буду использовать его всегда, а потом тратить время на поиск узких мест. Зачем писать неоптимально, если более быстрый вариант пишется нетрудно? Я же не ассемблерные вставки пишу. А то здесь два цикла, там два цикла, так и накопится снежный ком лишних действий, а потом поди разберись в нём.
Так а я и не ищу) Для работы нужно иметь кучу других качеств и навыков, кроме программирования на уровне любителя. Я пишу программы для своих задач и удовольствия, остальное меня не интересует.
Знаю и понимаю. Но функции - это не уникальная черта ФП. Портянку из for и if я дроблю на субфункции, когда становится непонятно, что происходит. И эти субфункции я могу назвать в соответствии с контекстом, не полагаясь на стандартное название из какой-то библиотеки.
Лапша - это когда в коде много связей между случайными участками, т.е. из многих мест идут обращения во многие места, из-за чего становится трудно понять, что на что влияет и как оно вообще работает. А длинный код не обязательно "лапша", его обычно можно разделить на отдельные функции, передавая результат от одной к другой.
Твой пример можно переписать читабельнее, но, во-первых, данными управлять должен сам элемент. Если данные нужно сохранить перед закрытием, то проверка и сохранение данных происходят в методе item.close(), а не в item.closeSiblings(), следовательно код упрощается.
Во-вторых, проверка открытости элемента производится опять же самим элементом в методе item.close(), потому что наше дело предложить ему закрыться, а ему решать, может ли он закрыться.
Тогда будет только:
А вот уже в close() будет что-то вроде:
В saveData():
...ну, ладно, один .forEach тут бы не повредил, типа
Но смысла в .filter() здесь не вижу. Фильтр был бы полезен, если бы мы потом с этим списком что-то сложное делали, т.е. сохраняли отдельно и редактировали...
А вообще я не пойму, в чём тут ФП? Это же императивные команды "сделай это", даже порядок соблюдается слева направо, а не наоборот. Против такого кода ничего не имею, пока названия функций имеют смысл (forEach = для каждого, в данном контексте нормально). Но большая часть виденного мной функционального кода читаемых имён не содержит (зато куча спецсимволов).
Так и мой код тоже поделён на мелкие (по возможности) функции. Только у моих функций название есть и соответствует контексту/области видимости, а в функциональщине названий либо нет, либо они из спецсимволов и скобок.
Тот же цикл forEach, по-хорошему, часть императивного кода:
Вот это максимально читаемый код, читается как русский язык:
А если оборачивать в скобки и спецсимволы, получается нечитабельная фигня.
Вообще я фанат алгол-подобных языков, хочу обмазываться длинными словами из букв и не хочу контактировать со спецсимволами. Увы, в вебе есть только JS, но я уже не против, тут не так много спецсимволов, как во всяких сях.
>из-за DOM, то есть обновления самой страницы и ререндеринга
Кстати, как это правильно делать, если нужно вывести (div.append()) сразу много элементов?
>это не имеет никакого значения пока у тебя в массивах меньше 10к элементов
Я обычно программирую как привык. И если привыкну к неоптимальному подходу, буду использовать его всегда, а потом тратить время на поиск узких мест. Зачем писать неоптимально, если более быстрый вариант пишется нетрудно? Я же не ассемблерные вставки пишу. А то здесь два цикла, там два цикла, так и накопится снежный ком лишних действий, а потом поди разберись в нём.
>найти работу
Так а я и не ищу) Для работы нужно иметь кучу других качеств и навыков, кроме программирования на уровне любителя. Я пишу программы для своих задач и удовольствия, остальное меня не интересует.
>читаемость и расширяемость
Знаю и понимаю. Но функции - это не уникальная черта ФП. Портянку из for и if я дроблю на субфункции, когда становится непонятно, что происходит. И эти субфункции я могу назвать в соответствии с контекстом, не полагаясь на стандартное название из какой-то библиотеки.
>получаешь лапшу
Лапша - это когда в коде много связей между случайными участками, т.е. из многих мест идут обращения во многие места, из-за чего становится трудно понять, что на что влияет и как оно вообще работает. А длинный код не обязательно "лапша", его обычно можно разделить на отдельные функции, передавая результат от одной к другой.
Твой пример можно переписать читабельнее, но, во-первых, данными управлять должен сам элемент. Если данные нужно сохранить перед закрытием, то проверка и сохранение данных происходят в методе item.close(), а не в item.closeSiblings(), следовательно код упрощается.
Во-вторых, проверка открытости элемента производится опять же самим элементом в методе item.close(), потому что наше дело предложить ему закрыться, а ему решать, может ли он закрыться.
Тогда будет только:
>for (let i in this.parent.items) if (this.parent.items[ i ] !== this) this.parent.items[ i ].close();
А вот уже в close() будет что-то вроде:
>if (this.opened) { this.saveData(); this.toogle(); }
В saveData():
>if (this.needToSave) { ... }
...ну, ладно, один .forEach тут бы не повредил, типа
>this.parent.items.forEach(item => { if (item !== this) item.close() });
Но смысла в .filter() здесь не вижу. Фильтр был бы полезен, если бы мы потом с этим списком что-то сложное делали, т.е. сохраняли отдельно и редактировали...
А вообще я не пойму, в чём тут ФП? Это же императивные команды "сделай это", даже порядок соблюдается слева направо, а не наоборот. Против такого кода ничего не имею, пока названия функций имеют смысл (forEach = для каждого, в данном контексте нормально). Но большая часть виденного мной функционального кода читаемых имён не содержит (зато куча спецсимволов).
>код поделён на мелкие функции
Так и мой код тоже поделён на мелкие (по возможности) функции. Только у моих функций название есть и соответствует контексту/области видимости, а в функциональщине названий либо нет, либо они из спецсимволов и скобок.
Тот же цикл forEach, по-хорошему, часть императивного кода:
>for item in items do if item <> self then item.close();
Вот это максимально читаемый код, читается как русский язык:
>для каждого итема в итемс проверяем что это не мы и закрываем соседей
А если оборачивать в скобки и спецсимволы, получается нечитабельная фигня.
Вообще я фанат алгол-подобных языков, хочу обмазываться длинными словами из букв и не хочу контактировать со спецсимволами. Увы, в вебе есть только JS, но я уже не против, тут не так много спецсимволов, как во всяких сях.
>>1233
Декларативные языки вообще несравнимы с императивными и имеют свою нишу, в которой императивные просто не нужны (пример - html).
Твой императивный пример:
- выйти на улицу:
- - одеться:
- - - снять домашнюю одежду
- - - надеть нижнее бельё
- - - надеть верхнюю одежду
- - обуться:
- - - надеть ботинки
- - - зашнуровать ботинки
- - надеть шапку
Он чётко описывает, что нужно сделать и как, задаёт последовательность. Машина просто считывает команды друг за другом и выполняет их как они есть, если они выполнимы данной машиной.
Декларативный:
- нужно выйти на улицу
- для выхода на улицу нужно быть одетым в уличную одежду, обутым и в шапке
- чтобы быть одетым, нужно надеть одежду
- чтобы надеть одежду, нужно снять одежду
- сейчас я в домашней одежде
- домашняя одежда это одежда
- уличная одежда это одежда
- чтобы быть в шапке, нужно надеть шапку
- чтобы быть обутым, нужно обуться
- чтобы обуться, нужна обувь
- ботинки это обувь
- после обувания в ботинки шнурки должны быть завязаны
и т.д. Я точно не знаю, набросал как сам понимаю.
Суть декларативного подхода в том, что ты просто сбрасываешь в одну кучу описания разных объектов и действий, а затем говоришь: "я хочу объект с такими-то характеристиками". И машина, используя описания объектов и действий, по каким-то своим алгоритмам находит способ создать требуемый объект, затем создаёт его и возвращает пользователю. Тебе не важно, как работает машина и какие решения она принимает для создания желаемого тобой объекта, тебе нужен только объект с какими-то характеристиками.
Вот более реальный пример:
Это декларативный подход. Мы говорим машине: мне нужна коробка размером 100 на 50 пикселей, с чёрным контуром в один пиксель толщиной и белой заливкой. Как и что она будет делать нас не волнует, нам нужен результат.
В императивном стиле было бы так:
Здесь мы явным образом задаём параметры конкретных инструментов (canvas, pen, brush) и используем их для создания прямоугольника конкретным способом (описанным в методе rectangle). Нам важно, чтобы задача была выполнена именно с помощью этих инструментов и именно в такой последовательности. Когда же мы описываем <div> в html, нам совершенно без разницы, что и как будет делать браузер, лишь бы результат соответствовал ожиданиям.
Короче, декларативный подход используется чаще, чем кажется, и не нужно на него фукать, у него просто своя область применения.
Декларативные языки вообще несравнимы с императивными и имеют свою нишу, в которой императивные просто не нужны (пример - html).
Твой императивный пример:
- выйти на улицу:
- - одеться:
- - - снять домашнюю одежду
- - - надеть нижнее бельё
- - - надеть верхнюю одежду
- - обуться:
- - - надеть ботинки
- - - зашнуровать ботинки
- - надеть шапку
Он чётко описывает, что нужно сделать и как, задаёт последовательность. Машина просто считывает команды друг за другом и выполняет их как они есть, если они выполнимы данной машиной.
Декларативный:
- нужно выйти на улицу
- для выхода на улицу нужно быть одетым в уличную одежду, обутым и в шапке
- чтобы быть одетым, нужно надеть одежду
- чтобы надеть одежду, нужно снять одежду
- сейчас я в домашней одежде
- домашняя одежда это одежда
- уличная одежда это одежда
- чтобы быть в шапке, нужно надеть шапку
- чтобы быть обутым, нужно обуться
- чтобы обуться, нужна обувь
- ботинки это обувь
- после обувания в ботинки шнурки должны быть завязаны
и т.д. Я точно не знаю, набросал как сам понимаю.
Суть декларативного подхода в том, что ты просто сбрасываешь в одну кучу описания разных объектов и действий, а затем говоришь: "я хочу объект с такими-то характеристиками". И машина, используя описания объектов и действий, по каким-то своим алгоритмам находит способ создать требуемый объект, затем создаёт его и возвращает пользователю. Тебе не важно, как работает машина и какие решения она принимает для создания желаемого тобой объекта, тебе нужен только объект с какими-то характеристиками.
Вот более реальный пример:
><div style="border: solid 1px black; width: 100px; height: 50px; background: white"></div>
Это декларативный подход. Мы говорим машине: мне нужна коробка размером 100 на 50 пикселей, с чёрным контуром в один пиксель толщиной и белой заливкой. Как и что она будет делать нас не волнует, нам нужен результат.
В императивном стиле было бы так:
>canvas.pen.color = black;
>canvas.pen.width = 1;
>canvas.brush.color = white;
>canvas.rectangle(0, 0, 100, 50);
Здесь мы явным образом задаём параметры конкретных инструментов (canvas, pen, brush) и используем их для создания прямоугольника конкретным способом (описанным в методе rectangle). Нам важно, чтобы задача была выполнена именно с помощью этих инструментов и именно в такой последовательности. Когда же мы описываем <div> в html, нам совершенно без разницы, что и как будет делать браузер, лишь бы результат соответствовал ожиданиям.
Короче, декларативный подход используется чаще, чем кажется, и не нужно на него фукать, у него просто своя область применения.
>>1233
Декларативные языки вообще несравнимы с императивными и имеют свою нишу, в которой императивные просто не нужны (пример - html).
Твой императивный пример:
- выйти на улицу:
- - одеться:
- - - снять домашнюю одежду
- - - надеть нижнее бельё
- - - надеть верхнюю одежду
- - обуться:
- - - надеть ботинки
- - - зашнуровать ботинки
- - надеть шапку
Он чётко описывает, что нужно сделать и как, задаёт последовательность. Машина просто считывает команды друг за другом и выполняет их как они есть, если они выполнимы данной машиной.
Декларативный:
- нужно выйти на улицу
- для выхода на улицу нужно быть одетым в уличную одежду, обутым и в шапке
- чтобы быть одетым, нужно надеть одежду
- чтобы надеть одежду, нужно снять одежду
- сейчас я в домашней одежде
- домашняя одежда это одежда
- уличная одежда это одежда
- чтобы быть в шапке, нужно надеть шапку
- чтобы быть обутым, нужно обуться
- чтобы обуться, нужна обувь
- ботинки это обувь
- после обувания в ботинки шнурки должны быть завязаны
и т.д. Я точно не знаю, набросал как сам понимаю.
Суть декларативного подхода в том, что ты просто сбрасываешь в одну кучу описания разных объектов и действий, а затем говоришь: "я хочу объект с такими-то характеристиками". И машина, используя описания объектов и действий, по каким-то своим алгоритмам находит способ создать требуемый объект, затем создаёт его и возвращает пользователю. Тебе не важно, как работает машина и какие решения она принимает для создания желаемого тобой объекта, тебе нужен только объект с какими-то характеристиками.
Вот более реальный пример:
Это декларативный подход. Мы говорим машине: мне нужна коробка размером 100 на 50 пикселей, с чёрным контуром в один пиксель толщиной и белой заливкой. Как и что она будет делать нас не волнует, нам нужен результат.
В императивном стиле было бы так:
Здесь мы явным образом задаём параметры конкретных инструментов (canvas, pen, brush) и используем их для создания прямоугольника конкретным способом (описанным в методе rectangle). Нам важно, чтобы задача была выполнена именно с помощью этих инструментов и именно в такой последовательности. Когда же мы описываем <div> в html, нам совершенно без разницы, что и как будет делать браузер, лишь бы результат соответствовал ожиданиям.
Короче, декларативный подход используется чаще, чем кажется, и не нужно на него фукать, у него просто своя область применения.
Декларативные языки вообще несравнимы с императивными и имеют свою нишу, в которой императивные просто не нужны (пример - html).
Твой императивный пример:
- выйти на улицу:
- - одеться:
- - - снять домашнюю одежду
- - - надеть нижнее бельё
- - - надеть верхнюю одежду
- - обуться:
- - - надеть ботинки
- - - зашнуровать ботинки
- - надеть шапку
Он чётко описывает, что нужно сделать и как, задаёт последовательность. Машина просто считывает команды друг за другом и выполняет их как они есть, если они выполнимы данной машиной.
Декларативный:
- нужно выйти на улицу
- для выхода на улицу нужно быть одетым в уличную одежду, обутым и в шапке
- чтобы быть одетым, нужно надеть одежду
- чтобы надеть одежду, нужно снять одежду
- сейчас я в домашней одежде
- домашняя одежда это одежда
- уличная одежда это одежда
- чтобы быть в шапке, нужно надеть шапку
- чтобы быть обутым, нужно обуться
- чтобы обуться, нужна обувь
- ботинки это обувь
- после обувания в ботинки шнурки должны быть завязаны
и т.д. Я точно не знаю, набросал как сам понимаю.
Суть декларативного подхода в том, что ты просто сбрасываешь в одну кучу описания разных объектов и действий, а затем говоришь: "я хочу объект с такими-то характеристиками". И машина, используя описания объектов и действий, по каким-то своим алгоритмам находит способ создать требуемый объект, затем создаёт его и возвращает пользователю. Тебе не важно, как работает машина и какие решения она принимает для создания желаемого тобой объекта, тебе нужен только объект с какими-то характеристиками.
Вот более реальный пример:
><div style="border: solid 1px black; width: 100px; height: 50px; background: white"></div>
Это декларативный подход. Мы говорим машине: мне нужна коробка размером 100 на 50 пикселей, с чёрным контуром в один пиксель толщиной и белой заливкой. Как и что она будет делать нас не волнует, нам нужен результат.
В императивном стиле было бы так:
>canvas.pen.color = black;
>canvas.pen.width = 1;
>canvas.brush.color = white;
>canvas.rectangle(0, 0, 100, 50);
Здесь мы явным образом задаём параметры конкретных инструментов (canvas, pen, brush) и используем их для создания прямоугольника конкретным способом (описанным в методе rectangle). Нам важно, чтобы задача была выполнена именно с помощью этих инструментов и именно в такой последовательности. Когда же мы описываем <div> в html, нам совершенно без разницы, что и как будет делать браузер, лишь бы результат соответствовал ожиданиям.
Короче, декларативный подход используется чаще, чем кажется, и не нужно на него фукать, у него просто своя область применения.
>>1459
Во-первых, зачем ты это все написал, если анон, которому ты отвечаешь, написал все то же самое, только короче.
Во-вторых, нить дискуссии была о том, с чего ТС взял то декларативное описание ЕСТЕСТВЕННЕЕ императивного. И вот теерь посмотри на свои описания алгоритмов в императивном и декларативном стиле, и скажи - какой из них ЕСТЕСТВЕННЕЕ для ЧЕЛОВЕКА.
Во-первых, зачем ты это все написал, если анон, которому ты отвечаешь, написал все то же самое, только короче.
Во-вторых, нить дискуссии была о том, с чего ТС взял то декларативное описание ЕСТЕСТВЕННЕЕ императивного. И вот теерь посмотри на свои описания алгоритмов в императивном и декларативном стиле, и скажи - какой из них ЕСТЕСТВЕННЕЕ для ЧЕЛОВЕКА.
>>1418
Я даже представить не могу что нужно делать, чтобы узким местом было использование filter и foreach вместо одного for, ты там совсем ебанулся? Ты мне почему-то напоминаешь одного чувака, который, когда учился играть на пианино, спрашивал какой стороной подушечки пальцев нужно нажимать на клавишу.
>И если привыкну к неоптимальному подходу, буду использовать его всегда, а потом тратить время на поиск узких мест.
Я даже представить не могу что нужно делать, чтобы узким местом было использование filter и foreach вместо одного for, ты там совсем ебанулся? Ты мне почему-то напоминаешь одного чувака, который, когда учился играть на пианино, спрашивал какой стороной подушечки пальцев нужно нажимать на клавишу.
Хочу тип, который бы принимал только те поля объекта (>Node), которые имеют тип Connection<любая хуйня>. Сделал вот так:
type Connection<T> = ...
type RequireConnection<T> = T extends Connection<infer X> ? T : never;
type Config<T extends Node, K extends keyof T> = {
connection: RequireConnection<T[K]>
...
}
При записи все нормально, иде подставляет нужные поля, но при чтении дженерика Config<any, any> она говорит А ВДРУХ БЛЯТЬ ВСЕТКИ НЕВЕР, и сует connection: any.
Что изменить?
type Connection<T> = ...
type RequireConnection<T> = T extends Connection<infer X> ? T : never;
type Config<T extends Node, K extends keyof T> = {
connection: RequireConnection<T[K]>
...
}
При записи все нормально, иде подставляет нужные поля, но при чтении дженерика Config<any, any> она говорит А ВДРУХ БЛЯТЬ ВСЕТКИ НЕВЕР, и сует connection: any.
Что изменить?
>>1510
Два цикла подряд вместо одного = в два раза дольше обработка данных.
>>1056
Я нашёл фатальный недостаток forEach:
Т.к. forEach - метод класса Array, если мы получаем откуда-то вместо массива пустышку, код валится с ошибкой. Можно вставить проверку на undefined, но зачем, если цикл for не сделает ни одной итерации безо всяких дополнительных проверок? Вместе с проверкой на undefined кода становится больше, чем с обычным циклом for.
Я создаю экземпляр класса, давая конструктору массив, в котором вторым элементом может быть вложенный массив, и конструктор создаёт вложенные экземпляры того же класса по той же схеме. Вложенность, естественно, ограничена размером стека, но мне хватит. Так вот последний по вложенности класс получает вместо массива undefined, т.к. в прошлом массиве был всего один элемент. С for работает без проверок, красиво и просто, с forEach придётся костылить проверку на undefined. Нибуду((
Два цикла подряд вместо одного = в два раза дольше обработка данных.
>>1056
>В твоем случае forEach и filter предпочитаемы
Я нашёл фатальный недостаток forEach:
>Error: Cannot read property 'forEach' of undefined
Т.к. forEach - метод класса Array, если мы получаем откуда-то вместо массива пустышку, код валится с ошибкой. Можно вставить проверку на undefined, но зачем, если цикл for не сделает ни одной итерации безо всяких дополнительных проверок? Вместе с проверкой на undefined кода становится больше, чем с обычным циклом for.
Я создаю экземпляр класса, давая конструктору массив, в котором вторым элементом может быть вложенный массив, и конструктор создаёт вложенные экземпляры того же класса по той же схеме. Вложенность, естественно, ограничена размером стека, но мне хватит. Так вот последний по вложенности класс получает вместо массива undefined, т.к. в прошлом массиве был всего один элемент. С for работает без проверок, красиво и просто, с forEach придётся костылить проверку на undefined. Нибуду((
>>1272
Нахуй серверу знать вьюпорт клиента, совсем поехавший? Или пердолишь свой ебаный styled components, абсолютно не зная, что у `<link>` есть аттрибут media, позволяющий условно загружать стили?
Нахуй серверу знать вьюпорт клиента, совсем поехавший? Или пердолишь свой ебаный styled components, абсолютно не зная, что у `<link>` есть аттрибут media, позволяющий условно загружать стили?
>>1639
Ты конечно же проводил тесты, а не просто фантазируешь?
>Два цикла подряд вместо одного = в два раза дольше обработка данных.
Ты конечно же проводил тесты, а не просто фантазируешь?
>>1669
я js учу с нуля
я js учу с нуля
>>1486
Естественнее в каком плане?
Если тебе нужно пошагово объяснить ребёнку/дебилу/старику/иностранцу какие-то действия для достижения какого-то результата - да, тут императивный подход только и можно применить. Чтобы человек не метался в панике и не пытался делать то, что делать опасно, неэффективно или бесполезно. Например, показываешь ребёнку, как надевать курточку - "левую ручку сюда, правую сюда, и смотри не прищеми пальчики молнией" (хотя последнее уже декларативное).
Если же тебе нужно дать задание взрослому здоровому адекватному человеку, тем более специалисту в какой-то области, то тебе достаточно сформировать запрос: "нужно то-то и то-то, в таком-то виде и объёме к такому дню". Ты же не будешь учить уборщицу мыть полы типа "воду наберите в ведро, тряпку макаете в воду и трёте тряпкой пол, пока вода не загрязнится, меняете воду и повторяете пока пол не станет чистым" (она посмотрит на тебя как на поехавшего), ты скажешь ей только "вот здесь чтобы пол был чистым, через час проверю".
Окей, уборщица может быть новенькой и не знать, где инвентарь. Но ты не говоришь ей "иди до двери, возьмись за ручку, открой дверь, отпусти ручку, наклонись, возьми ведро и швабру, закрой дверь ногой, развернись на 180 градусов, пройди до начальной точки". Ты говоришь ей "швабра и ведро находятся в подсобке, подсобка по коридору прямо за маленькой дверью". Дальше она сама находит в своей памяти нужную программу для достижения двери, извлечения инвентаря и его использования для мытья пола. Или не находит и увольняется))
То есть мы общаемся в основном в декларативном формате:
- подай соль
- принеси табуретку
- расскажи о прочитанной книге
- сделай мне сайт, где я буду весь такой хороший
- помогите решить задачку, вот ошибка, вот что хочу сделать, не выходит
И так далее. Мы не пишем программы, мы запрашиваем желаемый результат. Даже обучение не всегда основано только на создании программ - часто предлагается самому найти решение, эксперименты помогают в обучении.
>какой из них ЕСТЕСТВЕННЕЕ для ЧЕЛОВЕКА
Естественнее в каком плане?
Если тебе нужно пошагово объяснить ребёнку/дебилу/старику/иностранцу какие-то действия для достижения какого-то результата - да, тут императивный подход только и можно применить. Чтобы человек не метался в панике и не пытался делать то, что делать опасно, неэффективно или бесполезно. Например, показываешь ребёнку, как надевать курточку - "левую ручку сюда, правую сюда, и смотри не прищеми пальчики молнией" (хотя последнее уже декларативное).
Если же тебе нужно дать задание взрослому здоровому адекватному человеку, тем более специалисту в какой-то области, то тебе достаточно сформировать запрос: "нужно то-то и то-то, в таком-то виде и объёме к такому дню". Ты же не будешь учить уборщицу мыть полы типа "воду наберите в ведро, тряпку макаете в воду и трёте тряпкой пол, пока вода не загрязнится, меняете воду и повторяете пока пол не станет чистым" (она посмотрит на тебя как на поехавшего), ты скажешь ей только "вот здесь чтобы пол был чистым, через час проверю".
Окей, уборщица может быть новенькой и не знать, где инвентарь. Но ты не говоришь ей "иди до двери, возьмись за ручку, открой дверь, отпусти ручку, наклонись, возьми ведро и швабру, закрой дверь ногой, развернись на 180 градусов, пройди до начальной точки". Ты говоришь ей "швабра и ведро находятся в подсобке, подсобка по коридору прямо за маленькой дверью". Дальше она сама находит в своей памяти нужную программу для достижения двери, извлечения инвентаря и его использования для мытья пола. Или не находит и увольняется))
То есть мы общаемся в основном в декларативном формате:
- подай соль
- принеси табуретку
- расскажи о прочитанной книге
- сделай мне сайт, где я буду весь такой хороший
- помогите решить задачку, вот ошибка, вот что хочу сделать, не выходит
И так далее. Мы не пишем программы, мы запрашиваем желаемый результат. Даже обучение не всегда основано только на создании программ - часто предлагается самому найти решение, эксперименты помогают в обучении.
>>1486
Естественнее в каком плане?
Если тебе нужно пошагово объяснить ребёнку/дебилу/старику/иностранцу какие-то действия для достижения какого-то результата - да, тут императивный подход только и можно применить. Чтобы человек не метался в панике и не пытался делать то, что делать опасно, неэффективно или бесполезно. Например, показываешь ребёнку, как надевать курточку - "левую ручку сюда, правую сюда, и смотри не прищеми пальчики молнией" (хотя последнее уже декларативное).
Если же тебе нужно дать задание взрослому здоровому адекватному человеку, тем более специалисту в какой-то области, то тебе достаточно сформировать запрос: "нужно то-то и то-то, в таком-то виде и объёме к такому дню". Ты же не будешь учить уборщицу мыть полы типа "воду наберите в ведро, тряпку макаете в воду и трёте тряпкой пол, пока вода не загрязнится, меняете воду и повторяете пока пол не станет чистым" (она посмотрит на тебя как на поехавшего), ты скажешь ей только "вот здесь чтобы пол был чистым, через час проверю".
Окей, уборщица может быть новенькой и не знать, где инвентарь. Но ты не говоришь ей "иди до двери, возьмись за ручку, открой дверь, отпусти ручку, наклонись, возьми ведро и швабру, закрой дверь ногой, развернись на 180 градусов, пройди до начальной точки". Ты говоришь ей "швабра и ведро находятся в подсобке, подсобка по коридору прямо за маленькой дверью". Дальше она сама находит в своей памяти нужную программу для достижения двери, извлечения инвентаря и его использования для мытья пола. Или не находит и увольняется))
То есть мы общаемся в основном в декларативном формате:
- подай соль
- принеси табуретку
- расскажи о прочитанной книге
- сделай мне сайт, где я буду весь такой хороший
- помогите решить задачку, вот ошибка, вот что хочу сделать, не выходит
И так далее. Мы не пишем программы, мы запрашиваем желаемый результат. Даже обучение не всегда основано только на создании программ - часто предлагается самому найти решение, эксперименты помогают в обучении.
>какой из них ЕСТЕСТВЕННЕЕ для ЧЕЛОВЕКА
Естественнее в каком плане?
Если тебе нужно пошагово объяснить ребёнку/дебилу/старику/иностранцу какие-то действия для достижения какого-то результата - да, тут императивный подход только и можно применить. Чтобы человек не метался в панике и не пытался делать то, что делать опасно, неэффективно или бесполезно. Например, показываешь ребёнку, как надевать курточку - "левую ручку сюда, правую сюда, и смотри не прищеми пальчики молнией" (хотя последнее уже декларативное).
Если же тебе нужно дать задание взрослому здоровому адекватному человеку, тем более специалисту в какой-то области, то тебе достаточно сформировать запрос: "нужно то-то и то-то, в таком-то виде и объёме к такому дню". Ты же не будешь учить уборщицу мыть полы типа "воду наберите в ведро, тряпку макаете в воду и трёте тряпкой пол, пока вода не загрязнится, меняете воду и повторяете пока пол не станет чистым" (она посмотрит на тебя как на поехавшего), ты скажешь ей только "вот здесь чтобы пол был чистым, через час проверю".
Окей, уборщица может быть новенькой и не знать, где инвентарь. Но ты не говоришь ей "иди до двери, возьмись за ручку, открой дверь, отпусти ручку, наклонись, возьми ведро и швабру, закрой дверь ногой, развернись на 180 градусов, пройди до начальной точки". Ты говоришь ей "швабра и ведро находятся в подсобке, подсобка по коридору прямо за маленькой дверью". Дальше она сама находит в своей памяти нужную программу для достижения двери, извлечения инвентаря и его использования для мытья пола. Или не находит и увольняется))
То есть мы общаемся в основном в декларативном формате:
- подай соль
- принеси табуретку
- расскажи о прочитанной книге
- сделай мне сайт, где я буду весь такой хороший
- помогите решить задачку, вот ошибка, вот что хочу сделать, не выходит
И так далее. Мы не пишем программы, мы запрашиваем желаемый результат. Даже обучение не всегда основано только на создании программ - часто предлагается самому найти решение, эксперименты помогают в обучении.
>>1674
О, спасибо, про for in я узнал из предлагаемых шаблонов кода в редакторе, а for of загуглить не додумался. Это как раз то, чего мне не хватало.
>for of
О, спасибо, про for in я узнал из предлагаемых шаблонов кода в редакторе, а for of загуглить не додумался. Это как раз то, чего мне не хватало.
Привет, аноны, неdавно начал параллельно с основной работой поdрабатывать на смежном стеке, который мне интересен. Проблема в том, что работа заклuyчается в том, что мне скиdываuyт тз в телеге, а я в ответ архивом результат, потом dеньги на карту, dаже не знаuy как завут чела, который мне платит, лол. Вот тут заdумался, а веdь с этого наdо налоги платить, dа? Ну и вопрос куda и как и сколько и что буdет, если того? Там не много, буквально пара к в неdелuy, поэтому и не dумал об этом раньше...
>>1674
Когда у тебя будет 1 млн операций в секунду, тогда это будет иметь значение. Для массива из 10-100 элементов можешь хоть 10 циклов сделать.
Когда у тебя будет 1 млн операций в секунду, тогда это будет иметь значение. Для массива из 10-100 элементов можешь хоть 10 циклов сделать.
>>1685
Это все императивное.
В декларативном нет глаголов.
>- подай соль
>- принеси табуретку
>- расскажи о прочитанной книге
Это все императивное.
В декларативном нет глаголов.
>>1719
Даже в этом примере видно, что разница в пять раз. Добавь в конец третий цикл конструкции some и разница увеличится до 10 раз.
А теперь умножь таких конструкций по несколько штук на каждый чих, когда у тебя по всему проекту эти маленькие коллекции. Разница возрастает на порядки.
Даже в этом примере видно, что разница в пять раз. Добавь в конец третий цикл конструкции some и разница увеличится до 10 раз.
А теперь умножь таких конструкций по несколько штук на каждый чих, когда у тебя по всему проекту эти маленькие коллекции. Разница возрастает на порядки.
>>1722
0.00005 вместо 0.00001?
Которые все выполняются одновременно в одном потоке?
>разница в пять раз
0.00005 вместо 0.00001?
>А теперь умножь таких конструкций по несколько штук на каждый чих
Которые все выполняются одновременно в одном потоке?
>>1304
Энтри левел вкат: Functional Light JS - я бы советовал начинать всем с этого, прагматичное ФП, очень хорошо разжевываются самые основы. Книга полезна не только как вкат в ФП, а как учебник по JS и построению программ в целом. https://github.com/getify/Functional-Light-JS
Некст лвл вкат: Mostly Adequate Guide To FP - ФП с корабля на бал, намного больше терминологии и объясняются основы теории категорий, но если вдумчиво читать, то одно из самых приятных введений в функторы и монады которые я видел. Желательно хорошо знать JS перед чтением.
https://drive.google.com/file/d/1NAlmEylllMM5zS8xke6pd16k2ULvbBZ0/view?usp=sharing
Энтри левел вкат: Functional Light JS - я бы советовал начинать всем с этого, прагматичное ФП, очень хорошо разжевываются самые основы. Книга полезна не только как вкат в ФП, а как учебник по JS и построению программ в целом. https://github.com/getify/Functional-Light-JS
Некст лвл вкат: Mostly Adequate Guide To FP - ФП с корабля на бал, намного больше терминологии и объясняются основы теории категорий, но если вдумчиво читать, то одно из самых приятных введений в функторы и монады которые я видел. Желательно хорошо знать JS перед чтением.
https://drive.google.com/file/d/1NAlmEylllMM5zS8xke6pd16k2ULvbBZ0/view?usp=sharing
>>1724
Они выполняются последовательно. И у твоего кода всего 16мс между рендрфреймами, чтобы произвести вычисления.
Они выполняются последовательно. И у твоего кода всего 16мс между рендрфреймами, чтобы произвести вычисления.
>>1722
Они везде и есть. У меня на работе есть супер сложный редьюсер, которые наверное массивов 20 по 1000 объектов перебирает по несколько раз и всё это занимает 1.7 мс.
Все эти перфоманс дрочки это лишь отсутствие практического опыта разработки. Тот кто шарит понимает, что в вебе узкое место это апдейт DOM, а не джаваскрипт.
Они везде и есть. У меня на работе есть супер сложный редьюсер, которые наверное массивов 20 по 1000 объектов перебирает по несколько раз и всё это занимает 1.7 мс.
Все эти перфоманс дрочки это лишь отсутствие практического опыта разработки. Тот кто шарит понимает, что в вебе узкое место это апдейт DOM, а не джаваскрипт.
>>1736
Тот кто шарит, знает, что ничего тяжелого в апдейтах дома нет, если ты оставляешь рендеру достаточно времени во фрейме, для обновлений.
Тот кто шарит, знает, что ничего тяжелого в апдейтах дома нет, если ты оставляешь рендеру достаточно времени во фрейме, для обновлений.
>>1740
Да у тебя один Layout пересчитываться будет десятки миллисекунд спасибо реактоговну, дрочка на фреймы бред. Тот, кто шарит знает, что код пишется не для машины, а для человека в первую очередь, особенно на высокоуровневых языках программирования. Про фреймы будешь рассказывать коллегам, когда они охуеют из твоих for-if'ов и мутаций переменных и будет невозможно добавить новый функционал без ебли.
Да у тебя один Layout пересчитываться будет десятки миллисекунд спасибо реактоговну, дрочка на фреймы бред. Тот, кто шарит знает, что код пишется не для машины, а для человека в первую очередь, особенно на высокоуровневых языках программирования. Про фреймы будешь рассказывать коллегам, когда они охуеют из твоих for-if'ов и мутаций переменных и будет невозможно добавить новый функционал без ебли.
Салам, боги.
Помогите полному долбоёбу плз
почему response.status возвращает undefined? при том, что сервер отвечает кодом 200
Еще вопрос - почему в этом коде если поставить await перед fetch, то выскочит SyntaxError - требуется async функция, хотя в учебнике на learn.javascript подобное написание прокатывает?
Да, я полный нубас в js. И да, я на коне
Помогите полному долбоёбу плз
почему response.status возвращает undefined? при том, что сервер отвечает кодом 200
Еще вопрос - почему в этом коде если поставить await перед fetch, то выскочит SyntaxError - требуется async функция, хотя в учебнике на learn.javascript подобное написание прокатывает?
Да, я полный нубас в js. И да, я на коне
>>1735
И ты наверняка замерил, что твой код куда-то там не укладывается по времени и лагает? Ты же не просто так фантазируешь о преждевременных оптимизациях без всякого на то основания, правда?
И ты наверняка замерил, что твой код куда-то там не укладывается по времени и лагает? Ты же не просто так фантазируешь о преждевременных оптимизациях без всякого на то основания, правда?
Анончики, посоветуйте книг для вката в js с упором на обмен данными с сервером. Желательно поновее со свежим взглядом на ленгуадже и технологии. Можно и на английской мове
Вот такой экземпляр норм
https://mirlib.ru/knigi/programming/354045-mastering-javascript-a-complete-programming-guide-including-jquery-ajax-web-design-scripting-and-mobile-application-development.html
?
Вот такой экземпляр норм
https://mirlib.ru/knigi/programming/354045-mastering-javascript-a-complete-programming-guide-including-jquery-ajax-web-design-scripting-and-mobile-application-development.html
?
255 Кб, 512x512>>1339
Не слушай его. Ты всё правильно делаешь. Документация реакта на твоей стороне.
Не слушай его. Ты всё правильно делаешь. Документация реакта на твоей стороне.
>>1339
Мы например юзаем react-query. Вдарил useQuery и усе. Но хуй знает, что там под капотом
Мы например юзаем react-query. Вдарил useQuery и усе. Но хуй знает, что там под капотом
>>1953
Сук, а ты хорош.
>>1339
Если стремишься к реюзабельности компонента, его изолированности от окружения и тестируемости (хотя простые компоненты и так нехуй тестировать), то, очевидно, всю логику, в т.ч. IO поебень выносить в отдельные сущности, а клеить тонкой прослойкой типа контейнера, который осуществит необходимые подписки и пробросит пропсы в целевой компонент. Это если делать по уму. А ежели просто ебошить - то делай, как удобно.
Сук, а ты хорош.
>>1339
Если стремишься к реюзабельности компонента, его изолированности от окружения и тестируемости (хотя простые компоненты и так нехуй тестировать), то, очевидно, всю логику, в т.ч. IO поебень выносить в отдельные сущности, а клеить тонкой прослойкой типа контейнера, который осуществит необходимые подписки и пробросит пропсы в целевой компонент. Это если делать по уму. А ежели просто ебошить - то делай, как удобно.
Анон зацени, сделал свой эксклюзивный ЙОБА-слайдер, на энтот раз без ебаного жиквери, все на чистом жиэс. Рейт.
Я уже могу устраиваться на зп в 100к?
Я уже могу устраиваться на зп в 100к?
>>1977
Манифик.
Манифик.
Как принято в ангуляре:
1. Нужно соединить 1 обсерваблу из самого компонента, и одну сверху. Если кроме как тут она нигде не нужна, то передавать сверху собственно готовую обсерваблу, или простое значение, а в компоненте уже пулять локальную по изменению?
2. В методичке просят переданное сверху не мутировать, но в то же время реактивные формы этим внаглую занимаются, т.е. их считают за сервис, хотя они не инжектятся, а дриллятся. Как тогда понять, когда это норм, а когда зашквар?
1. Нужно соединить 1 обсерваблу из самого компонента, и одну сверху. Если кроме как тут она нигде не нужна, то передавать сверху собственно готовую обсерваблу, или простое значение, а в компоненте уже пулять локальную по изменению?
2. В методичке просят переданное сверху не мутировать, но в то же время реактивные формы этим внаглую занимаются, т.е. их считают за сервис, хотя они не инжектятся, а дриллятся. Как тогда понять, когда это норм, а когда зашквар?
>>2005
Купишь у меня код?
Купишь у меня код?
>>1977
А инкапсулировать будет кто, Пушкин? Без инкапсуляции и с константами прямо в логике твой слайдер может быть только один на странице, на которой кроме него нет никаких картинок (ты же вообще все <img> зохавал?).
Нужен класс:
class ImageSlider {
constructor(name, images, owner) {}
}
Где:
- name определяет CSS-класс, по которым один слайдер отличает элементы других слайдером от своих. Все картинки и кнопки должны иметь этот класс.
- images определяет набор картинок, которые нужно воткнуть в этот слайдер, потому что создавать мы его будем динамически (кому нужна статическая страница с жыс-слайдером картинок в 2021?).
- owner определяет элемент, к которому этот слайдер сам себя добавит (чтобы нам не нужно было его вручную добавлять, просто сделал new ImageSlider() и забыл про него, пока не понадобится удалить).
А инкапсулировать будет кто, Пушкин? Без инкапсуляции и с константами прямо в логике твой слайдер может быть только один на странице, на которой кроме него нет никаких картинок (ты же вообще все <img> зохавал?).
Нужен класс:
class ImageSlider {
constructor(name, images, owner) {}
}
Где:
- name определяет CSS-класс, по которым один слайдер отличает элементы других слайдером от своих. Все картинки и кнопки должны иметь этот класс.
- images определяет набор картинок, которые нужно воткнуть в этот слайдер, потому что создавать мы его будем динамически (кому нужна статическая страница с жыс-слайдером картинок в 2021?).
- owner определяет элемент, к которому этот слайдер сам себя добавит (чтобы нам не нужно было его вручную добавлять, просто сделал new ImageSlider() и забыл про него, пока не понадобится удалить).
>>1977
>>2023
Забыл ещё, ты перезаписываешь свойство стиля display, а что если тебе нужно картинки отображать не как block? У этого свойства много значений.
Правильнее будет присвоить картинкам определённый класс, в нём обозначить свойство display и присвоить ему нужное значение (block или что угодно другое кроме none), а в твоём коде вместо display = "block" делать просто display = "". Так восстановится значение класса, перезаписанное присвоением display = "none". А первоначальное присвоение none должно быть в конструкторе класса, который размещает предложенные картинки внутри слайдера.
Сам недавно переписывал свой код, когда потребовалось абстрагироваться от значения "block", решение оказалось неожиданно простым.
>>2023
Забыл ещё, ты перезаписываешь свойство стиля display, а что если тебе нужно картинки отображать не как block? У этого свойства много значений.
Правильнее будет присвоить картинкам определённый класс, в нём обозначить свойство display и присвоить ему нужное значение (block или что угодно другое кроме none), а в твоём коде вместо display = "block" делать просто display = "". Так восстановится значение класса, перезаписанное присвоением display = "none". А первоначальное присвоение none должно быть в конструкторе класса, который размещает предложенные картинки внутри слайдера.
Сам недавно переписывал свой код, когда потребовалось абстрагироваться от значения "block", решение оказалось неожиданно простым.
>>2030
Он ведь нужен только если ты что-то возвращаешь. Если нечего возвращать, то и ретурн не нужен. А если ты что-то хочешь вернуть, то как ты забываешь про ретурн? Во большинстве языков возвращаемое значение нужно куда-то присвоить/передать явным образом.
Он ведь нужен только если ты что-то возвращаешь. Если нечего возвращать, то и ретурн не нужен. А если ты что-то хочешь вернуть, то как ты забываешь про ретурн? Во большинстве языков возвращаемое значение нужно куда-то присвоить/передать явным образом.
>>2029
Согласен, переписал на изменение классов сплавным переходом.
Про конструктор на классах читал. Но вот энта инкапсуляция на практике пока мне не попадалась, все что ты написал я понял. Но реализовать на практике пока не хватает опыта.
Согласен, переписал на изменение классов сплавным переходом.
Про конструктор на классах читал. Но вот энта инкапсуляция на практике пока мне не попадалась, все что ты написал я понял. Но реализовать на практике пока не хватает опыта.
>>2029
Спасибо! Хоршего дня.
Спасибо! Хоршего дня.
>>2045
однозначно нет
однозначно нет
274 Кб, 860x1932>>2034
Я недавно вот такую менюшку себе сделал, суть такова: есть меню с выбором вариантов ответа, каждый вариант может быть вложенным меню со своим набором вариантов ответа, и так далее. То есть рекурсивная структура. Сделано просто рекурсивным созданием новых объектов одного и того же класса, а запускается созданием самого первого объекта передачей в него всей необходимой информации. Внешний вид, цвета, расположение и форма, даже сортировка (выбранный пункт поднимается наверх, к заголовку группы) - это всё на CSS, на JS только логика создания/открытия/закрытия группы и передача результата (тому, кто создал это меню) с его самоуничтожением в случае успешной обработки результата. По-моему гениально, осталось только отрефакторить и убрать мусор из кода. Короче, без инкапсуляции в класс это было бы намного труднее сделать.
Вряд ли кому-то понадобится делать галерею в галерее в галерее, но несколько одинаковых галерей на одной странице - это очень распространённая ситуация, например, в газетных статьях и на страницах-демонстрациях какой-нибудь программы/библиотеки/технологии.
Это очень просто на JS, сравнивая с другими ЯП)
>инкапсуляция на практике пока мне не попадалась
Я недавно вот такую менюшку себе сделал, суть такова: есть меню с выбором вариантов ответа, каждый вариант может быть вложенным меню со своим набором вариантов ответа, и так далее. То есть рекурсивная структура. Сделано просто рекурсивным созданием новых объектов одного и того же класса, а запускается созданием самого первого объекта передачей в него всей необходимой информации. Внешний вид, цвета, расположение и форма, даже сортировка (выбранный пункт поднимается наверх, к заголовку группы) - это всё на CSS, на JS только логика создания/открытия/закрытия группы и передача результата (тому, кто создал это меню) с его самоуничтожением в случае успешной обработки результата. По-моему гениально, осталось только отрефакторить и убрать мусор из кода. Короче, без инкапсуляции в класс это было бы намного труднее сделать.
Вряд ли кому-то понадобится делать галерею в галерее в галерее, но несколько одинаковых галерей на одной странице - это очень распространённая ситуация, например, в газетных статьях и на страницах-демонстрациях какой-нибудь программы/библиотеки/технологии.
>реализовать на практике пока не хватает опыта
Это очень просто на JS, сравнивая с другими ЯП)
решил задачу лучше, чем писюха с хабра https://habr.com/ru/post/351874/
чсв поднялося
чсв поднялося
>>1014
https://habr.com/ru/company/vdsina/blog/544218/
Это просто к слову о том, почему задумываться о том, как код будет работать с большим объёмом данных - полезно, даже если сейчас ты не собираешься загружать его такими объёмами.
>нет смысла делать эти микрооптимизации
https://habr.com/ru/company/vdsina/blog/544218/
>O(n^2) — оптимальное время для плохо масштабируемых алгоритмов — достаточно быстро, чтобы попасть в продакшен, но достаточно медленно, чтобы ломать всё, после того, как он туда попал.
>Если вы пишете код, который будут запускать другие, то убедитесь, что он достаточно хорошо масштабируется для обработки любого возможного множества данных, вне зависимости от его разумности. Квадратичные алгоритмы обычно проваливают эту проверку.
Это просто к слову о том, почему задумываться о том, как код будет работать с большим объёмом данных - полезно, даже если сейчас ты не собираешься загружать его такими объёмами.
>>2249
Ну пиздец открыли америку канеш
Алсо, в чем проблема делать фетч в компоненте, а потом полученное записывать в стор? При условии что запрос в компоненте уникальный. Это просто для удобства организации кода делается?
Ну пиздец открыли америку канеш
Алсо, в чем проблема делать фетч в компоненте, а потом полученное записывать в стор? При условии что запрос в компоненте уникальный. Это просто для удобства организации кода делается?
>>2249
Экшены будут а actions created вызываться как и раньше , только уже будет функция которая диспатчит через ac результат работы метода из api.ts, все обращения в внешним ресурсам будут в одном файле
>экшены
Экшены будут а actions created вызываться как и раньше , только уже будет функция которая диспатчит через ac результат работы метода из api.ts, все обращения в внешним ресурсам будут в одном файле
В чем прикол делать запросы внутри компонентов? Это же пиздец нелогично и как это потом все мокать для тестов?
У меня все проходит через сервис, который состояние запросов записывает в стор, а компоненты лишь отрисовывают контент в зависимости от состояния стора и наличия данных в кешируемых хранилищах данных.
У меня все проходит через сервис, который состояние запросов записывает в стор, а компоненты лишь отрисовывают контент в зависимости от состояния стора и наличия данных в кешируемых хранилищах данных.
Какже JS пиздат, есть ли что то понятнее и пизже чем он?
в плане других языков
в плане других языков
>>2340
а я думал ты питон скажешь
а я думал ты питон скажешь
>>2334
Elm, Reason, любой другой язык ML семейства.
Elm, Reason, любой другой язык ML семейства.
>>2401
Лол. Пиздец же так трудно типы указать, да? А без тайпскрипта потом сидишь и охуеваешь, в каком месте у тебя число стало строкой в тридцатикратно вложенном компоненте
>кодить становится труднее
Лол. Пиздец же так трудно типы указать, да? А без тайпскрипта потом сидишь и охуеваешь, в каком месте у тебя число стало строкой в тридцатикратно вложенном компоненте
>>2424
Лол, я сам большую часть сознательной жизни кодил только на строго типизированных языках (Паскаль и подобные ему). Так что я знаю, зачем нужны типы, регулярно создавал новые и всегда указывал их (иначе не складируется), а от слабо типизированных языков шарахался. Но сейчас понимаю, что слепить прототип программы без указания типов на порядок быстрее и проще, а ошибки если и бывают, то не критичны - не прошивку ракеты/самолёта же кодим. Но я-то опытный, хоть и любитель, а вот новичкам, конечно, слабо типизированные языки только вредят, имхо.
И часто оно у тебя так случается? По-моему это возможно только когда ты пытаешься сложить строку с числом, вместо сложения происходит конкатенация. Зачем, спрашивается, делать конкатенацию там, где она не нужна?
Ты должен делать тесты каждого уровня вложенности начиная от первого изменённого уровня до самого верхнего. Сделал изменение - провёл тест и убедился, что всё работает. Как только тест показывает ошибку, ты уже знаешь, что эта ошибка возникла из-за последнего внесённого тобой изменения, потому что до этого все компоненты тесты проходили успешно. Ну или у тебя ошибка в тесте, лол)) А если ты тестов не делаешь и пишешь сотни строк кода без единой проверки - зачем ругаться на язык? Сам виноват.
Меня вот Паскаль приучил тестить программу после каждой строчки/изменения в коде. Даже после написания комментария предпочитаю перекомпилировать, а то вдруг где-то что-то поломал. Ну а с JS всё ещё проще: компиляции как таковой нет, достаточно переключиться на браузер и нажать F5, все изменения и возможные ошибки будут сразу же явно видны. Т.е. городить систему типов особого смысла нет, зато время на выдумывание этой самой системы уходит намного больше, что замедляет прототипирование.
Вот, например, ты боишься, что у тебя integer превратится в string. Но это цветочки, ты не должен указывать x: integer, ты должен придумать новый тип, например, TValue = Integer, а затем следить за тем, чтобы TValue не попадало в Integer, потому что это разные типы, хоть и числовые. В языке Ада такие проверки из коробки, но вряд ли тебе понравится на ней программировать (очень долго и очень трудно выдумывать новые типы)...
Лол, я сам большую часть сознательной жизни кодил только на строго типизированных языках (Паскаль и подобные ему). Так что я знаю, зачем нужны типы, регулярно создавал новые и всегда указывал их (иначе не складируется), а от слабо типизированных языков шарахался. Но сейчас понимаю, что слепить прототип программы без указания типов на порядок быстрее и проще, а ошибки если и бывают, то не критичны - не прошивку ракеты/самолёта же кодим. Но я-то опытный, хоть и любитель, а вот новичкам, конечно, слабо типизированные языки только вредят, имхо.
>число стало строкой
И часто оно у тебя так случается? По-моему это возможно только когда ты пытаешься сложить строку с числом, вместо сложения происходит конкатенация. Зачем, спрашивается, делать конкатенацию там, где она не нужна?
>тридцатикратно вложенном компоненте
Ты должен делать тесты каждого уровня вложенности начиная от первого изменённого уровня до самого верхнего. Сделал изменение - провёл тест и убедился, что всё работает. Как только тест показывает ошибку, ты уже знаешь, что эта ошибка возникла из-за последнего внесённого тобой изменения, потому что до этого все компоненты тесты проходили успешно. Ну или у тебя ошибка в тесте, лол)) А если ты тестов не делаешь и пишешь сотни строк кода без единой проверки - зачем ругаться на язык? Сам виноват.
Меня вот Паскаль приучил тестить программу после каждой строчки/изменения в коде. Даже после написания комментария предпочитаю перекомпилировать, а то вдруг где-то что-то поломал. Ну а с JS всё ещё проще: компиляции как таковой нет, достаточно переключиться на браузер и нажать F5, все изменения и возможные ошибки будут сразу же явно видны. Т.е. городить систему типов особого смысла нет, зато время на выдумывание этой самой системы уходит намного больше, что замедляет прототипирование.
Вот, например, ты боишься, что у тебя integer превратится в string. Но это цветочки, ты не должен указывать x: integer, ты должен придумать новый тип, например, TValue = Integer, а затем следить за тем, чтобы TValue не попадало в Integer, потому что это разные типы, хоть и числовые. В языке Ада такие проверки из коробки, но вряд ли тебе понравится на ней программировать (очень долго и очень трудно выдумывать новые типы)...
>>2424
Лол, я сам большую часть сознательной жизни кодил только на строго типизированных языках (Паскаль и подобные ему). Так что я знаю, зачем нужны типы, регулярно создавал новые и всегда указывал их (иначе не складируется), а от слабо типизированных языков шарахался. Но сейчас понимаю, что слепить прототип программы без указания типов на порядок быстрее и проще, а ошибки если и бывают, то не критичны - не прошивку ракеты/самолёта же кодим. Но я-то опытный, хоть и любитель, а вот новичкам, конечно, слабо типизированные языки только вредят, имхо.
И часто оно у тебя так случается? По-моему это возможно только когда ты пытаешься сложить строку с числом, вместо сложения происходит конкатенация. Зачем, спрашивается, делать конкатенацию там, где она не нужна?
Ты должен делать тесты каждого уровня вложенности начиная от первого изменённого уровня до самого верхнего. Сделал изменение - провёл тест и убедился, что всё работает. Как только тест показывает ошибку, ты уже знаешь, что эта ошибка возникла из-за последнего внесённого тобой изменения, потому что до этого все компоненты тесты проходили успешно. Ну или у тебя ошибка в тесте, лол)) А если ты тестов не делаешь и пишешь сотни строк кода без единой проверки - зачем ругаться на язык? Сам виноват.
Меня вот Паскаль приучил тестить программу после каждой строчки/изменения в коде. Даже после написания комментария предпочитаю перекомпилировать, а то вдруг где-то что-то поломал. Ну а с JS всё ещё проще: компиляции как таковой нет, достаточно переключиться на браузер и нажать F5, все изменения и возможные ошибки будут сразу же явно видны. Т.е. городить систему типов особого смысла нет, зато время на выдумывание этой самой системы уходит намного больше, что замедляет прототипирование.
Вот, например, ты боишься, что у тебя integer превратится в string. Но это цветочки, ты не должен указывать x: integer, ты должен придумать новый тип, например, TValue = Integer, а затем следить за тем, чтобы TValue не попадало в Integer, потому что это разные типы, хоть и числовые. В языке Ада такие проверки из коробки, но вряд ли тебе понравится на ней программировать (очень долго и очень трудно выдумывать новые типы)...
Лол, я сам большую часть сознательной жизни кодил только на строго типизированных языках (Паскаль и подобные ему). Так что я знаю, зачем нужны типы, регулярно создавал новые и всегда указывал их (иначе не складируется), а от слабо типизированных языков шарахался. Но сейчас понимаю, что слепить прототип программы без указания типов на порядок быстрее и проще, а ошибки если и бывают, то не критичны - не прошивку ракеты/самолёта же кодим. Но я-то опытный, хоть и любитель, а вот новичкам, конечно, слабо типизированные языки только вредят, имхо.
>число стало строкой
И часто оно у тебя так случается? По-моему это возможно только когда ты пытаешься сложить строку с числом, вместо сложения происходит конкатенация. Зачем, спрашивается, делать конкатенацию там, где она не нужна?
>тридцатикратно вложенном компоненте
Ты должен делать тесты каждого уровня вложенности начиная от первого изменённого уровня до самого верхнего. Сделал изменение - провёл тест и убедился, что всё работает. Как только тест показывает ошибку, ты уже знаешь, что эта ошибка возникла из-за последнего внесённого тобой изменения, потому что до этого все компоненты тесты проходили успешно. Ну или у тебя ошибка в тесте, лол)) А если ты тестов не делаешь и пишешь сотни строк кода без единой проверки - зачем ругаться на язык? Сам виноват.
Меня вот Паскаль приучил тестить программу после каждой строчки/изменения в коде. Даже после написания комментария предпочитаю перекомпилировать, а то вдруг где-то что-то поломал. Ну а с JS всё ещё проще: компиляции как таковой нет, достаточно переключиться на браузер и нажать F5, все изменения и возможные ошибки будут сразу же явно видны. Т.е. городить систему типов особого смысла нет, зато время на выдумывание этой самой системы уходит намного больше, что замедляет прототипирование.
Вот, например, ты боишься, что у тебя integer превратится в string. Но это цветочки, ты не должен указывать x: integer, ты должен придумать новый тип, например, TValue = Integer, а затем следить за тем, чтобы TValue не попадало в Integer, потому что это разные типы, хоть и числовые. В языке Ада такие проверки из коробки, но вряд ли тебе понравится на ней программировать (очень долго и очень трудно выдумывать новые типы)...
>>1733
12 страница, там где автор сначала пишет через класс Flock - реально надо минимум когнитивных способностей чтобы понять что происходит. Потом начинает городить фп ересь, где уже реально нихуя не понятно сходу. Вот и ответ о применимости фп как подхода.
>Mostly Adequate Guide To FP
12 страница, там где автор сначала пишет через класс Flock - реально надо минимум когнитивных способностей чтобы понять что происходит. Потом начинает городить фп ересь, где уже реально нихуя не понятно сходу. Вот и ответ о применимости фп как подхода.
>>2433
Вот именно что прототип, для большого приложения чистый js это пиздец полный, мне по крайне мере от него просто блевать тянет. Даже если через неделю к коду вернешься уже нихуя непонятно куда какие объекты передаются и какие у них поля/методы. А так у меня даже с ts бывают ошибки когда я неправильно тип возвращаемый с бэка указываю, боюсь представить что бы было если бы вся прилага была без ts.
Я что долбоеб запоминать какие значения у меня могут быть undefined, чтобы проверки добавлять? Тем более в ts есть пиздатый синтаксис object?.field. Короче ванильный js это калище дикое, а ts тупо кайф.
>Но сейчас понимаю, что слепить прототип программы без указания типов на порядок быстрее и проще
Вот именно что прототип, для большого приложения чистый js это пиздец полный, мне по крайне мере от него просто блевать тянет. Даже если через неделю к коду вернешься уже нихуя непонятно куда какие объекты передаются и какие у них поля/методы. А так у меня даже с ts бывают ошибки когда я неправильно тип возвращаемый с бэка указываю, боюсь представить что бы было если бы вся прилага была без ts.
Я что долбоеб запоминать какие значения у меня могут быть undefined, чтобы проверки добавлять? Тем более в ts есть пиздатый синтаксис object?.field. Короче ванильный js это калище дикое, а ts тупо кайф.
>>2433
Никому я ничего не должен, и вообще в тайпскрипте структурная типизация
>ты не должен указывать x: integer, ты должен придумать новый тип, например, TValue = Integer,
Никому я ничего не должен, и вообще в тайпскрипте структурная типизация
>>2476
А ты не всегда можешь знать наверняка. Я буквально недавно пилил бэк для личного проекта и решил не заморачиваться с тайпскриптом, в итоге я напридумывал новых фич и следить за всем и держать все типы в памяти стало очень больно. В итоге пришлось все на ts переписывать.
>>2496
Я лично по настоящему больших проектах не писал, но участвовал по крайне мере в средних и везде использовался тайпскрипт, а там где не использовался был постепенный переход. Был еще проект, где некоторые типы в комментах указывались, не помню уже как такой подход называется, но как по мне проще уже реальный ts подключить.
Не то чтобы я дохуя сеньер, но по моему личному опыту ts выручал дохуя раз.
А ты не всегда можешь знать наверняка. Я буквально недавно пилил бэк для личного проекта и решил не заморачиваться с тайпскриптом, в итоге я напридумывал новых фич и следить за всем и держать все типы в памяти стало очень больно. В итоге пришлось все на ts переписывать.
>>2496
Я лично по настоящему больших проектах не писал, но участвовал по крайне мере в средних и везде использовался тайпскрипт, а там где не использовался был постепенный переход. Был еще проект, где некоторые типы в комментах указывались, не помню уже как такой подход называется, но как по мне проще уже реальный ts подключить.
Не то чтобы я дохуя сеньер, но по моему личному опыту ts выручал дохуя раз.
>>1977
Сейчас бы в нынешнем году менять стили заместо изменения аттрибута src у картинки. На крайняк можно хранить три картинки и их подгружать.
Сейчас бы в нынешнем году менять стили заместо изменения аттрибута src у картинки. На крайняк можно хранить три картинки и их подгружать.
>>2602
Через месяц попробую, щас дрочу колбеки, замыкания и прототипное наследование в функциях
Через месяц попробую, щас дрочу колбеки, замыкания и прототипное наследование в функциях
Каким образом в реакте используется классовый синтаксис, если не используются классовые компоненты? Есть пример? Какие-нибудь репозитории, в которых можно посмотреть как все сделано? А то фриланшу сейчас на реакте, делаю все на функциональных, но хочу стать полноценным рабом, а на собесах наверняка про всё вот это вот спросят
>>2602
Без жс надо будет всю галлерею хранить на странице, лол.
Конечно можно попердолитья с ленивой загрузкой, но один хуй будет дохуя элементов в доме сидеть.
Без жс надо будет всю галлерею хранить на странице, лол.
Конечно можно попердолитья с ленивой загрузкой, но один хуй будет дохуя элементов в доме сидеть.
>>2303
В чем именно по-твоему заключается проблема замокать запрос внутри компонента?
Который работает магическим образом сам по себе, и к которому компоненты не обращаются вообще никак и не говорят ему, что фетчить и когда?
>Это же пиздец нелогично и как это потом все мокать для тестов?
В чем именно по-твоему заключается проблема замокать запрос внутри компонента?
>У меня все проходит через сервис
Который работает магическим образом сам по себе, и к которому компоненты не обращаются вообще никак и не говорят ему, что фетчить и когда?
>>2703
Просто делаешь в начале файла с компонентом import api from 'services/api'
И потом в компоненте где нужно вызываешь api.getSomeData()
Просто делаешь в начале файла с компонентом import api from 'services/api'
И потом в компоненте где нужно вызываешь api.getSomeData()
>>2722
И что это по-твоему, если не "делать запросы внутри компонентов"? Чем твое api.getSomeData() отличается от fetch(), и почему ты считаешь, что первое вдруг мокабельное, а второе нет?
И что это по-твоему, если не "делать запросы внутри компонентов"? Чем твое api.getSomeData() отличается от fetch(), и почему ты считаешь, что первое вдруг мокабельное, а второе нет?
>>2727
Я мимо проходил, хз что там про моки. Это лучше тем, что всё спрятано в service/api, в компоненте ты только функцию вызываешь которая возвращает response либо ошибку если она была.
Вот тут другой анон уже писал про это: >>2278
Удобнее держать все обращения к апи с клиента в одном месте
>>2724
Каким боком тут ООП? api может быть просто объектом с методами.
const api = {
getSomeData() {
// тут фетч
}
}
Я мимо проходил, хз что там про моки. Это лучше тем, что всё спрятано в service/api, в компоненте ты только функцию вызываешь которая возвращает response либо ошибку если она была.
Вот тут другой анон уже писал про это: >>2278
Удобнее держать все обращения к апи с клиента в одном месте
>>2724
Каким боком тут ООП? api может быть просто объектом с методами.
const api = {
getSomeData() {
// тут фетч
}
}
>>2735
То есть импортиурешь ВЕСЬ объект, чтобы вызвать функцию у него? Ты вообще в курсе как ES6 модули работают?
>Каким боком тут ООП? api может быть просто объектом с методами.
То есть импортиурешь ВЕСЬ объект, чтобы вызвать функцию у него? Ты вообще в курсе как ES6 модули работают?
>>2743
Как раз адепты ООП и не могут в ES6 импорты.
Как раз адепты ООП и не могут в ES6 импорты.
Где я успел обосраться?
https://developer.mozilla.org/en-US/docs/Learn/Getting_started_with_the_web/JavaScript_basics#adding_an_image_changer
Здесь пример
let myImage = document.querySelector('img');
myImage.onclick = function() {
let mySrc = myImage.getAttribute('src');
if(mySrc === 'images/firefox-icon.png') {
myImage.setAttribute('src','images/firefox2.png');
} else {
myImage.setAttribute('src','images/firefox-icon.png');
}
}
У меня в myImage на первой же строчке не записывается атрибут src. В итоге onclick не cрабатывает. Чому так?
https://developer.mozilla.org/en-US/docs/Learn/Getting_started_with_the_web/JavaScript_basics#adding_an_image_changer
Здесь пример
let myImage = document.querySelector('img');
myImage.onclick = function() {
let mySrc = myImage.getAttribute('src');
if(mySrc === 'images/firefox-icon.png') {
myImage.setAttribute('src','images/firefox2.png');
} else {
myImage.setAttribute('src','images/firefox-icon.png');
}
}
У меня в myImage на первой же строчке не записывается атрибут src. В итоге onclick не cрабатывает. Чому так?
>>2771
Эм. Я нуль, ты имеешь в виду, что если вот у меня слева нет src, то он и не возьмется в переменную? Или под показом дом ты что имеешь в виду? Консоль пустая.
Сука, че за пример такой на первой же странице по js для желторотиков, который не работает.
Эм. Я нуль, ты имеешь в виду, что если вот у меня слева нет src, то он и не возьмется в переменную? Или под показом дом ты что имеешь в виду? Консоль пустая.
Сука, че за пример такой на первой же странице по js для желторотиков, который не работает.
>>2454
Поэтому я и скахал что про лвл вкат. Никто не говорит, что ФП это 1 страницу книжки прочитал и выучил за день. Если выглядит как ересь, значит у тебя либо мало опыта разработки, либо опыт твой это писанина на реакте была.
Без опыта это месяц как минимум изучения подхода к написанию кода и обработке данных, ведь нужна практика, конечно же. Зато потом ты становишься намного лучше разработчиком даже на ООП, даже если ФП не используешь в повседневном кодинге, мозги прокачиваются хорошо.
Поэтому я и скахал что про лвл вкат. Никто не говорит, что ФП это 1 страницу книжки прочитал и выучил за день. Если выглядит как ересь, значит у тебя либо мало опыта разработки, либо опыт твой это писанина на реакте была.
Без опыта это месяц как минимум изучения подхода к написанию кода и обработке данных, ведь нужна практика, конечно же. Зато потом ты становишься намного лучше разработчиком даже на ООП, даже если ФП не используешь в повседневном кодинге, мозги прокачиваются хорошо.
>>2784
Короче, нахуй src.
document.querySelector('html').onclick = function() {
alert('Ouch! Stop poking me!');
}
работает, а
document.querySelector('img').onclick = function() {
alert('Ouch! Stop poking me!');
}
нет.
Короче, нахуй src.
document.querySelector('html').onclick = function() {
alert('Ouch! Stop poking me!');
}
работает, а
document.querySelector('img').onclick = function() {
alert('Ouch! Stop poking me!');
}
нет.
>>2334
Руби в диапазоне легко писать/легко читать примерно на том же уровне, что и JS.
Из статических С#/TypeScript пожалуй.
Руби в диапазоне легко писать/легко читать примерно на том же уровне, что и JS.
Из статических С#/TypeScript пожалуй.
Здравствуйте, у меня проблема с библиотекой Chart.js, конкретно не могу изменить ширину графика типа line - он растягивается на всю страницу.
указываю размеры здесь:
<div class="container">
<canvas id="lineChart" width="600" height="400"></canvas>
</div>
высота графика меняется, а ширина всегда остаётся одной и той же.
пробовал в опциях графика разные комбинации responsive:false и maintainAspectRatio: false, но ничего не помогло. Так же прописал Chart.defaults.global.maintainAspectRatio = false; (до этого даже высоту нельзя было поменять)
Подскажите пожалуйста, что делать?
указываю размеры здесь:
<div class="container">
<canvas id="lineChart" width="600" height="400"></canvas>
</div>
высота графика меняется, а ширина всегда остаётся одной и той же.
пробовал в опциях графика разные комбинации responsive:false и maintainAspectRatio: false, но ничего не помогло. Так же прописал Chart.defaults.global.maintainAspectRatio = false; (до этого даже высоту нельзя было поменять)
Подскажите пожалуйста, что делать?
>>2762
Затем что вот здесь хуйню спизданули:
>>2703
Если кто-то несёт хуйню, то почему бы не поправит его? Но тут походу безнадежный случай, человеку ООП мерещится там, где его нет. Вкатыш походу
Затем что вот здесь хуйню спизданули:
>>2703
> Который работает магическим образом сам по себе, и к которому компоненты не обращаются вообще никак и не говорят ему, что фетчить и когда?
Если кто-то несёт хуйню, то почему бы не поправит его? Но тут походу безнадежный случай, человеку ООП мерещится там, где его нет. Вкатыш походу
>>2303
Ну ты все правильно делаешь.
Вообще реакт должен отвечать исключительно за UI. Все остальное должно быть за его пределами. Именно поэтому хуки по типу useReducer и useEffect налево направо превращают реакт в лапшу из сайд эффектов. Мне кажется во времена классовых компонентов они выглядели хоть и более многословными, но почище.
Ну ты все правильно делаешь.
Вообще реакт должен отвечать исключительно за UI. Все остальное должно быть за его пределами. Именно поэтому хуки по типу useReducer и useEffect налево направо превращают реакт в лапшу из сайд эффектов. Мне кажется во времена классовых компонентов они выглядели хоть и более многословными, но почище.
196 Кб, 1280x1104Почитал пасту про вкат. Вы ебанулись? Чтобы вкатиться веб-макакичем джуном мне надо учить прототипы, хулиард фреймворков, вебпаки, говнопаки? За 30к рублей? Зп кассира в Магните.
>>2829
Дело в том, что для того, чтобы быть сеньером, тебе нужно знать ровно всё то же самоое
Дело в том, что для того, чтобы быть сеньером, тебе нужно знать ровно всё то же самоое
Есть классы A, B, C.
В классе C есть конструктор, в котором инициализируется условная конфигурация, получаемая от объектов класса A и B.
В классе C есть так же статичные методы, которые задействую эту информации и выводят на экран.
Учитывая асинхронность ноды, мое приложение выглядит так:
const a = new A();
a.run(...);
const b = new B();
b.run(...);
const c = new C(a.getInfo(), b.getInfo());
c.run(...);
В экземплярах объектов a и b метод run(...) вызывает те самые статичные методы класса C.staticMethod() и выводит корректно информацию, хотя конструктор этого класса еще не был вызван, а значит информации от a и b там быть не должно.
Даже, если представить, что конструктор C вызвался раньше, чем отработал любой из методов run(...) a и b, и вывел эту информацию, то можно заблокировать главный поток перед инициализацией c на 5 секунд, но метод run(...) объектов a и b все равно выводит корректную информацию статичными методами по расписанию и без задержек, после чего через те самые 5 секунд срабатывает вывод из конструктора C, что подтверждает то, что главны1 поток был прерван до вызового этого конструктора.
Почему так?
В классе C есть конструктор, в котором инициализируется условная конфигурация, получаемая от объектов класса A и B.
В классе C есть так же статичные методы, которые задействую эту информации и выводят на экран.
Учитывая асинхронность ноды, мое приложение выглядит так:
const a = new A();
a.run(...);
const b = new B();
b.run(...);
const c = new C(a.getInfo(), b.getInfo());
c.run(...);
В экземплярах объектов a и b метод run(...) вызывает те самые статичные методы класса C.staticMethod() и выводит корректно информацию, хотя конструктор этого класса еще не был вызван, а значит информации от a и b там быть не должно.
Даже, если представить, что конструктор C вызвался раньше, чем отработал любой из методов run(...) a и b, и вывел эту информацию, то можно заблокировать главный поток перед инициализацией c на 5 секунд, но метод run(...) объектов a и b все равно выводит корректную информацию статичными методами по расписанию и без задержек, после чего через те самые 5 секунд срабатывает вывод из конструктора C, что подтверждает то, что главны1 поток был прерван до вызового этого конструктора.
Почему так?
>>2847
Я думаю что все адекваты спят, а ты сидишь от нехуй делать и скроллишь ночной. Еще и не понимаешь нихуя, но почему-то решаешь, что можешь говорить за всех, лол.
Я думаю что все адекваты спят, а ты сидишь от нехуй делать и скроллишь ночной. Еще и не понимаешь нихуя, но почему-то решаешь, что можешь говорить за всех, лол.
>>2851
>начал вертеть жопой и петросянить, вместо того, чтобы просто попросить больше информации
>получил ответ в таком же стиле
>рррряяяяя не огрызайся дай пример лучше
>буквально на пальцах, оперируя тремя буквами/объектами, объяснил все изначально максимально подробно с кодом в 3 строки
Подскажите тупице. Я сделал небольшой проект с роутами, сбилдил, закинул на бесплатный хостинг, все работает, но если зайти на роут и перегрузить страницу, то ошибка 404. Как это решается?
>>2828
Вызывать запросы всё равно где-то нужно, если нужна загрузка данных при маунте компонента, то кроме как в useEffect больше негде это делать
Вызывать запросы всё равно где-то нужно, если нужна загрузка данных при маунте компонента, то кроме как в useEffect больше негде это делать
>>2828
За UI должен отвечать html/css. Жабаскрипт - за логику.
Яскозал?
То ли дело вызывать сайд-эффекты через глобальный стор. Зато ООП!
Это ты ебанину с дублирующей логикой назвал "почище"?
>Вообще реакт должен отвечать исключительно за UI.
За UI должен отвечать html/css. Жабаскрипт - за логику.
>Все остальное должно быть за его пределами.
Яскозал?
>Именно поэтому хуки по типу useReducer и useEffect налево направо превращают реакт в лапшу из сайд эффектов.
То ли дело вызывать сайд-эффекты через глобальный стор. Зато ООП!
>Мне кажется во времена классовых компонентов они выглядели хоть и более многословными, но почище.
Это ты ебанину с дублирующей логикой назвал "почище"?
>>2861
Как там в 2010?
Конкретно реакт — библиотека для отображения UI.
Что не так? Это самая удобная модель.
Где в редаксе ООП? Ты вообще понимаешь о чём говоришь, или просто так бредишь лишь бы спиздануть?
мимокрокодил
> За UI должен отвечать html/css
Как там в 2010?
> Жабаскрипт - за логику.
Конкретно реакт — библиотека для отображения UI.
> То ли дело вызывать сайд-эффекты через глобальный стор
Что не так? Это самая удобная модель.
> Зато ООП!
Где в редаксе ООП? Ты вообще понимаешь о чём говоришь, или просто так бредишь лишь бы спиздануть?
мимокрокодил
>>2845
В общем, я разобрался, все работало правильно и конструктор C все-таки срабатывал раньше, чем вызывались его статичные методы внутри методов A и B.
В общем, я разобрался, все работало правильно и конструктор C все-таки срабатывал раньше, чем вызывались его статичные методы внутри методов A и B.
>>2834
Кстати да, два года уже повышает зп, а сижу все на том же говне, такое чувство что ничего нового и не изучаю.
Кстати да, два года уже повышает зп, а сижу все на том же говне, такое чувство что ничего нового и не изучаю.
>>2877
От сюда появляется вопрос: как лучше спроектировать классы? Ведь то что у меня сейчас, это неправильно.
У меня в одном приложении есть 3 основных класса: Server, Database и Console.
Server - обрабатывает http запросы.
Database - работает с бд, обновляет в ней информацию и т.п.
Console - интерактивная обертка над stdin, позволяет вводить команды для экземпляров Server и Database.
Сonsole в своем конструкторе вызывает конструктор класса Messages, который содержит информацию о конфигурации и состояниях экземпляров Server и Database.
Код: https://pastebin.com/EM5nrVEx
В самом низу я закомментировал свое решение этой проблемы, оно самое очевидное, но хочется как-то сделать все универсальным, чтобы порядок вызова конструкторов и методов был не важен при этом сохранить класс Messages, потому что мне нравится, когда есть всего один класс со всеми возможными сообщениями, вызов которых происходит повторно в разных участках кода.
Повторю проблему: конструкторы ClassConsole и ClassMessages могут (и делают это в данном примере) срабатывать позже отработки методов run() экземпляров ClassServer и ClassDatabase. Как можно изменить архитектуру классов, чтобы получить универсальную и независимую работу этих классов?
От сюда появляется вопрос: как лучше спроектировать классы? Ведь то что у меня сейчас, это неправильно.
У меня в одном приложении есть 3 основных класса: Server, Database и Console.
Server - обрабатывает http запросы.
Database - работает с бд, обновляет в ней информацию и т.п.
Console - интерактивная обертка над stdin, позволяет вводить команды для экземпляров Server и Database.
Сonsole в своем конструкторе вызывает конструктор класса Messages, который содержит информацию о конфигурации и состояниях экземпляров Server и Database.
Код: https://pastebin.com/EM5nrVEx
В самом низу я закомментировал свое решение этой проблемы, оно самое очевидное, но хочется как-то сделать все универсальным, чтобы порядок вызова конструкторов и методов был не важен при этом сохранить класс Messages, потому что мне нравится, когда есть всего один класс со всеми возможными сообщениями, вызов которых происходит повторно в разных участках кода.
Повторю проблему: конструкторы ClassConsole и ClassMessages могут (и делают это в данном примере) срабатывать позже отработки методов run() экземпляров ClassServer и ClassDatabase. Как можно изменить архитектуру классов, чтобы получить универсальную и независимую работу этих классов?
>>2896
Т.е. Messages вынести на один уровень с Server, Database и Console? Я думал об этом, но как-то странно выглядит, нелогично.
Т.е. Messages вынести на один уровень с Server, Database и Console? Я думал об этом, но как-то странно выглядит, нелогично.
>>2898
От того что ты его используешь как неявную зависимость - менее значимым он не становится
От того что ты его используешь как неявную зависимость - менее значимым он не становится
>>2898
Также, я не знаю что у тебя console делает, он он похоже должен имплентировать IMessages и называться ConsoleMessageLogger.
Если тебе еще и контроллер нужен, делаешь IController и ConsoleController. Жаль что интерфейсов то нет. Если консоли еще нет, а писать в нее уже нужно, пишешь буферизующий декторатор для логгера. Ммм, ООП.
Также, я не знаю что у тебя console делает, он он похоже должен имплентировать IMessages и называться ConsoleMessageLogger.
Если тебе еще и контроллер нужен, делаешь IController и ConsoleController. Жаль что интерфейсов то нет. Если консоли еще нет, а писать в нее уже нужно, пишешь буферизующий декторатор для логгера. Ммм, ООП.
>>2889
Выглядит как бэковый код, поэтому можешь присмотреться к typedi, он удобно реализует dependency injection архитектуру, возможно тебе полезным окажется.
Выглядит как бэковый код, поэтому можешь присмотреться к typedi, он удобно реализует dependency injection архитектуру, возможно тебе полезным окажется.
175 Кб, 750x1334>>2889
Не по теме твоего вопроса, но: откуда такое именование у тебя появилось? Это можно теперь так делать или ты сам придумал?
Мимо дед
Не по теме твоего вопроса, но: откуда такое именование у тебя появилось? Это можно теперь так делать или ты сам придумал?
Мимо дед
>>2911
Дед, ну яву же встроили в этот ваш жаваскрипт, теперь с инкапсуляцией. Инкапсулируй на здоровье
Дед, ну яву же встроили в этот ваш жаваскрипт, теперь с инкапсуляцией. Инкапсулируй на здоровье
>>2901
Возможно. Просто я такой человек, который может часами думать над названием переменной, поэтому подобного рода проектирования для меня - лютый пиздец.
>>2906
Ничего особого не делает да и не будет, скорее всего, только число команд будет расти. Вот реальный код на текущий момент: https://pastebin.com/jqeeVYDW
Про существование интерфейсов я уже и забыл, даже не помню для чего они нужны. Спасибо, почитаю.
>>2909
Я хочу свести к минимуму использование готовых библиотек/фреймворков. Пишу в первую очередь с целью понять/изучить.
>>2911
Можно, если имя не зарезервировано. В моем случае server и database работают, console тоже, но начинаются проблемы, когда нужно в этом же коде вызывать console.log(). Надо наверное лучше сразу тогда придумать какой-то префикс для полей класса (для экземпляров объектов он уже есть).
Возможно. Просто я такой человек, который может часами думать над названием переменной, поэтому подобного рода проектирования для меня - лютый пиздец.
>>2906
Ничего особого не делает да и не будет, скорее всего, только число команд будет расти. Вот реальный код на текущий момент: https://pastebin.com/jqeeVYDW
Про существование интерфейсов я уже и забыл, даже не помню для чего они нужны. Спасибо, почитаю.
>>2909
Я хочу свести к минимуму использование готовых библиотек/фреймворков. Пишу в первую очередь с целью понять/изучить.
>>2911
Можно, если имя не зарезервировано. В моем случае server и database работают, console тоже, но начинаются проблемы, когда нужно в этом же коде вызывать console.log(). Надо наверное лучше сразу тогда придумать какой-то префикс для полей класса (для экземпляров объектов он уже есть).
>>2915
Какие проблемы у тебя начинаются при такой ситуации?
>console тоже, но начинаются проблемы, когда нужно в этом же коде вызывать console.log()
Какие проблемы у тебя начинаются при такой ситуации?
>>2915
Да я прекрасно знаю, что можно. Можно даже кириллицей переменную объявить, но не лучше ли придерживаться общепринятому стилю кода? Сейчас может быть ты пишешь исключительно для себя, но однажды, если планируешь связаться с программированием, ты будешь трудиться в составе Команды. Лучше уже сегодня привыкать к тому как принято
>Можно, если имя не зарезервировано
Да я прекрасно знаю, что можно. Можно даже кириллицей переменную объявить, но не лучше ли придерживаться общепринятому стилю кода? Сейчас может быть ты пишешь исключительно для себя, но однажды, если планируешь связаться с программированием, ты будешь трудиться в составе Команды. Лучше уже сегодня привыкать к тому как принято
>>2922
О чем ты, друг?
О чем ты, друг?
>>2916
const server = new ClassServer('server');
const db = new ClassServer('db');
const console = new ClassConsole(server, db);
console.log('asdas');
const server = new ClassServer('server');
const db = new ClassServer('db');
const console = new ClassConsole(server, db);
console.log('asdas');
>ReferenceError: Cannot access 'console' before initialization
>>2924
Ты в конструкторе классСервер используешь консоль.лог, а ниже по коду зачем-то переопределяешь переменную консоль. Потому и не можешь ее есипользлвать
Ты в конструкторе классСервер используешь консоль.лог, а ниже по коду зачем-то переопределяешь переменную консоль. Потому и не можешь ее есипользлвать
>>2924
А теперь попробуй разнести все по модулям, как положено, а не лепить все в одном пространстве имен в один файл. И проверь еще раз.
А теперь попробуй разнести все по модулям, как положено, а не лепить все в одном пространстве имен в один файл. И проверь еще раз.
>>2928
>>2930
Если я привел код в пример, это не значит что я его использую. Просто иногда для быстрого дебажного лога проще что-то подобное написать и стереть сразу же. Поэтому в main() у меня не console, а lfConsole = new LFConsole(...), но в полях классов я еще не придумал правила именования, потому что конфликтов не было, потом исправлю.
>>2930
Если я привел код в пример, это не значит что я его использую. Просто иногда для быстрого дебажного лога проще что-то подобное написать и стереть сразу же. Поэтому в main() у меня не console, а lfConsole = new LFConsole(...), но в полях классов я еще не придумал правила именования, потому что конфликтов не было, потом исправлю.
>>2915
в методе stop() лучше вызывай остановку сервера, дисконнект бд и остановку процесса, а в кейсе defines.COMMAND_CONSOLE_EXIT вызывай this.stop()
в методе stop() лучше вызывай остановку сервера, дисконнект бд и остановку процесса, а в кейсе defines.COMMAND_CONSOLE_EXIT вызывай this.stop()
>>2944
Да, исправил.
Да, исправил.
mobx
>>2915
Чувак, если ты хочешь _изучить_, то изучать надо то, что наработано другими.
Понимаешь?
Пытаться понять, почему так, а не иначе.
Много читать (код и книги), и не очень много писать (больше заметок, чем кода).
И только потом - пытаться делать своё.
Иначе будет такая же хуита, как и у других 16-ти летних мидлов и синьёров, прости г-споди. Которых, почему-то, никто не хочет брать на работу.
>Я хочу свести к минимуму использование готовых библиотек/фреймворков. Пишу в первую очередь с целью понять/изучить.
Чувак, если ты хочешь _изучить_, то изучать надо то, что наработано другими.
Понимаешь?
Пытаться понять, почему так, а не иначе.
Много читать (код и книги), и не очень много писать (больше заметок, чем кода).
И только потом - пытаться делать своё.
Иначе будет такая же хуита, как и у других 16-ти летних мидлов и синьёров, прости г-споди. Которых, почему-то, никто не хочет брать на работу.
>>3026
Вообще с тобой не согласен. Читая чужой код, ты учишься делать чужие ошибки, а не только получаешь какую-то полезную информацию. Эту информацию нужно еще и самому обработать. И выходит, что это ни чем не отличается от обычного самообучения на практике. Дохуя людей, которые пишут код, считают себя синьорами, рубят 300к/нсек, а на деле хуи моржовые с клавиатурой в руках. Почему в софте, над которым трудятся сотни человек, имеет ту же сотню багов, которые "фиксят" и находят новые? Не потому что код пишут 16 летние мидлы, а потому что это люди, которые считают что делают что-то лучше и правильней, другой считает по своему, третий аналогично и т.д. Все доходит до того, что ведущий погромист, видит это написанное говно, мерджит в мастер и ахуевает, потому что он 100ый в этом списке, да и вообще он написал даже книгу свою по архитектуре кода, которая выстрелила и ее до дыр читает другая сотня-тысяча вайтишников-шахтеров, которые потом с ноги ворвутся за своими 300к/нсек, щеманут омежек и начнут диктовать свои условия команде. Все это конечно утрирование, но примерно так оно все и работает на самом деле.
А что я? Я просто сижу и по фану пишу свой код, в котором я ориентируюсь. Пишу программки для себя, начиная с меньшего, чтобы потом написать что-то большее, например, свою игру. Поэтому да, чем меньше я использую прослойки в коде, которые скрыты, тем больше я понимаю код и имею над ним контроль. Никогда не понимал выскочек, которые про велосипеды что-то там бормочат. Велосипеды - это хорошо, если ты понимаешь зачем он тебе нужен.
Я учился еще в вузике на погромиста, закончил, но интерес к нему у меня пропал. Я не работал ни в каких командах, все что писал выше это не более, чем мой субъективный взгляд на вещи со стороны. Ну а спустя годы, я просто решил к этому говну вернуться и расшевелить его. Ни на какие лавры не претендую, устраиваться никуда не хочу, но хочу понимать свой код и иметь контроль над ним. По возможности использовать более элегантные решения, я же все-таки не против клир кода и прочих концепций в подходе к написанию его, что-то даже в памяти еще осталось после вуза.
Вообще с тобой не согласен. Читая чужой код, ты учишься делать чужие ошибки, а не только получаешь какую-то полезную информацию. Эту информацию нужно еще и самому обработать. И выходит, что это ни чем не отличается от обычного самообучения на практике. Дохуя людей, которые пишут код, считают себя синьорами, рубят 300к/нсек, а на деле хуи моржовые с клавиатурой в руках. Почему в софте, над которым трудятся сотни человек, имеет ту же сотню багов, которые "фиксят" и находят новые? Не потому что код пишут 16 летние мидлы, а потому что это люди, которые считают что делают что-то лучше и правильней, другой считает по своему, третий аналогично и т.д. Все доходит до того, что ведущий погромист, видит это написанное говно, мерджит в мастер и ахуевает, потому что он 100ый в этом списке, да и вообще он написал даже книгу свою по архитектуре кода, которая выстрелила и ее до дыр читает другая сотня-тысяча вайтишников-шахтеров, которые потом с ноги ворвутся за своими 300к/нсек, щеманут омежек и начнут диктовать свои условия команде. Все это конечно утрирование, но примерно так оно все и работает на самом деле.
А что я? Я просто сижу и по фану пишу свой код, в котором я ориентируюсь. Пишу программки для себя, начиная с меньшего, чтобы потом написать что-то большее, например, свою игру. Поэтому да, чем меньше я использую прослойки в коде, которые скрыты, тем больше я понимаю код и имею над ним контроль. Никогда не понимал выскочек, которые про велосипеды что-то там бормочат. Велосипеды - это хорошо, если ты понимаешь зачем он тебе нужен.
Я учился еще в вузике на погромиста, закончил, но интерес к нему у меня пропал. Я не работал ни в каких командах, все что писал выше это не более, чем мой субъективный взгляд на вещи со стороны. Ну а спустя годы, я просто решил к этому говну вернуться и расшевелить его. Ни на какие лавры не претендую, устраиваться никуда не хочу, но хочу понимать свой код и иметь контроль над ним. По возможности использовать более элегантные решения, я же все-таки не против клир кода и прочих концепций в подходе к написанию его, что-то даже в памяти еще осталось после вуза.
>>3026
Вообще с тобой не согласен. Читая чужой код, ты учишься делать чужие ошибки, а не только получаешь какую-то полезную информацию. Эту информацию нужно еще и самому обработать. И выходит, что это ни чем не отличается от обычного самообучения на практике. Дохуя людей, которые пишут код, считают себя синьорами, рубят 300к/нсек, а на деле хуи моржовые с клавиатурой в руках. Почему в софте, над которым трудятся сотни человек, имеет ту же сотню багов, которые "фиксят" и находят новые? Не потому что код пишут 16 летние мидлы, а потому что это люди, которые считают что делают что-то лучше и правильней, другой считает по своему, третий аналогично и т.д. Все доходит до того, что ведущий погромист, видит это написанное говно, мерджит в мастер и ахуевает, потому что он 100ый в этом списке, да и вообще он написал даже книгу свою по архитектуре кода, которая выстрелила и ее до дыр читает другая сотня-тысяча вайтишников-шахтеров, которые потом с ноги ворвутся за своими 300к/нсек, щеманут омежек и начнут диктовать свои условия команде. Все это конечно утрирование, но примерно так оно все и работает на самом деле.
А что я? Я просто сижу и по фану пишу свой код, в котором я ориентируюсь. Пишу программки для себя, начиная с меньшего, чтобы потом написать что-то большее, например, свою игру. Поэтому да, чем меньше я использую прослойки в коде, которые скрыты, тем больше я понимаю код и имею над ним контроль. Никогда не понимал выскочек, которые про велосипеды что-то там бормочат. Велосипеды - это хорошо, если ты понимаешь зачем он тебе нужен.
Я учился еще в вузике на погромиста, закончил, но интерес к нему у меня пропал. Я не работал ни в каких командах, все что писал выше это не более, чем мой субъективный взгляд на вещи со стороны. Ну а спустя годы, я просто решил к этому говну вернуться и расшевелить его. Ни на какие лавры не претендую, устраиваться никуда не хочу, но хочу понимать свой код и иметь контроль над ним. По возможности использовать более элегантные решения, я же все-таки не против клир кода и прочих концепций в подходе к написанию его, что-то даже в памяти еще осталось после вуза.
Вообще с тобой не согласен. Читая чужой код, ты учишься делать чужие ошибки, а не только получаешь какую-то полезную информацию. Эту информацию нужно еще и самому обработать. И выходит, что это ни чем не отличается от обычного самообучения на практике. Дохуя людей, которые пишут код, считают себя синьорами, рубят 300к/нсек, а на деле хуи моржовые с клавиатурой в руках. Почему в софте, над которым трудятся сотни человек, имеет ту же сотню багов, которые "фиксят" и находят новые? Не потому что код пишут 16 летние мидлы, а потому что это люди, которые считают что делают что-то лучше и правильней, другой считает по своему, третий аналогично и т.д. Все доходит до того, что ведущий погромист, видит это написанное говно, мерджит в мастер и ахуевает, потому что он 100ый в этом списке, да и вообще он написал даже книгу свою по архитектуре кода, которая выстрелила и ее до дыр читает другая сотня-тысяча вайтишников-шахтеров, которые потом с ноги ворвутся за своими 300к/нсек, щеманут омежек и начнут диктовать свои условия команде. Все это конечно утрирование, но примерно так оно все и работает на самом деле.
А что я? Я просто сижу и по фану пишу свой код, в котором я ориентируюсь. Пишу программки для себя, начиная с меньшего, чтобы потом написать что-то большее, например, свою игру. Поэтому да, чем меньше я использую прослойки в коде, которые скрыты, тем больше я понимаю код и имею над ним контроль. Никогда не понимал выскочек, которые про велосипеды что-то там бормочат. Велосипеды - это хорошо, если ты понимаешь зачем он тебе нужен.
Я учился еще в вузике на погромиста, закончил, но интерес к нему у меня пропал. Я не работал ни в каких командах, все что писал выше это не более, чем мой субъективный взгляд на вещи со стороны. Ну а спустя годы, я просто решил к этому говну вернуться и расшевелить его. Ни на какие лавры не претендую, устраиваться никуда не хочу, но хочу понимать свой код и иметь контроль над ним. По возможности использовать более элегантные решения, я же все-таки не против клир кода и прочих концепций в подходе к написанию его, что-то даже в памяти еще осталось после вуза.
>>3073
Перезапустил апп. Теперь выдаёт такое, когда тест зафейлился
Дроч с конфигами — главная боль фронтенда имхо
Перезапустил апп. Теперь выдаёт такое, когда тест зафейлился
Дроч с конфигами — главная боль фронтенда имхо
>>3068
Ебать ты альтернативно одарённый.
А не читая чужой код, ты обречён сделать все те ошибки, которые уже были сделаны до тебя, за всю историю программирования, плюс добавить ещё и своих уникальных тараканов.
Но, вообще, каждому - своё.
Кто-то - перфекционист.
А кто-то - онанист.
> Читая чужой код, ты учишься делать чужие ошибки,
Ебать ты альтернативно одарённый.
А не читая чужой код, ты обречён сделать все те ошибки, которые уже были сделаны до тебя, за всю историю программирования, плюс добавить ещё и своих уникальных тараканов.
Но, вообще, каждому - своё.
Кто-то - перфекционист.
А кто-то - онанист.
>>3090
Во-первых, со стрикт-режимом где?
Во-вторых - как это меняет тот факт, что JS - дрисня, а TS - рулит?
И что единственный способ починить JS - это писать тонны JSDoc комментариев, в которых, в итоге, получается сильно больше знаков, чем если бы ты писал типы в TS?
Во-первых, со стрикт-режимом где?
Во-вторых - как это меняет тот факт, что JS - дрисня, а TS - рулит?
И что единственный способ починить JS - это писать тонны JSDoc комментариев, в которых, в итоге, получается сильно больше знаков, чем если бы ты писал типы в TS?
>>3094
Речь была вообще о том, что нельзя однозначно сказать "читай чужой код - становись профессионалом". Чаще даже узнаешь что-то новое/полезное, когда сам пишешь и пробуешь разные варианты, эксперементируешь, а сидеть книжным червем и надрачивать на макконела или ковырять гит такого же самоучки - это дорога хуй пойми куда и зачем, в которой ты идешь только по наитию и принимаешь все за чистую монету. Я не против книг и поиска информации из всех возможных источников, но говорить "иди ковыряй чужой код и читай мою любимую книжку, иначе не стать тебе погромистом" это... Действительно, каждому свое, тут не поспоришь даже.
Речь была вообще о том, что нельзя однозначно сказать "читай чужой код - становись профессионалом". Чаще даже узнаешь что-то новое/полезное, когда сам пишешь и пробуешь разные варианты, эксперементируешь, а сидеть книжным червем и надрачивать на макконела или ковырять гит такого же самоучки - это дорога хуй пойми куда и зачем, в которой ты идешь только по наитию и принимаешь все за чистую монету. Я не против книг и поиска информации из всех возможных источников, но говорить "иди ковыряй чужой код и читай мою любимую книжку, иначе не стать тебе погромистом" это... Действительно, каждому свое, тут не поспоришь даже.
>>3103
Должна быть природная интуиция, чтобы отличать добро от говна.
И, если она есть, то чтение правильного чужого кода и правильных книг - это великое благо.
>или ковырять гит такого же самоучки
Должна быть природная интуиция, чтобы отличать добро от говна.
И, если она есть, то чтение правильного чужого кода и правильных книг - это великое благо.
>читай книжки
>смотри код
>интуитивно
>станешь синьором
хуя шиза в вакууме
>>3106
И чем отличается анализ незнакомого тебе кода от написания кода, когда оба этих процесса изначально основываются на интуиции с твоих же слов?
И чем отличается анализ незнакомого тебе кода от написания кода, когда оба этих процесса изначально основываются на интуиции с твоих же слов?
>>3147
carbon.now.sh
carbon.now.sh
Алярм, мужички. Я сделал небольшой проект с роутами, сбилдил, закинул на бесплатный хостинг, все работает, но если зайти на роут и перегрузить страницу, то ошибка 404. Как это решается?
>>3245
Советую вкатится в вебпак, ручками настроить вебпакдэвсервер, тогда все поймёшь , cra заставляет неверно конфигурировать package.json, дропай эту хуету, один раз напишеш шаблонный конфиг и все будет заебца
Советую вкатится в вебпак, ручками настроить вебпакдэвсервер, тогда все поймёшь , cra заставляет неверно конфигурировать package.json, дропай эту хуету, один раз напишеш шаблонный конфиг и все будет заебца
>>3089
Это ж фича бабеля - плагины конфигов пресетов.
>>3098
ЖСдоковые каменты по крайней мере в тело функции не протекают и ими можно назначать тип функциональным объявлениям. И проиграл от количества знаков, какая тебе нахуй разница сколько там знаков в сырцах?
>Дроч с конфигами — главная боль фронтенда имхо
Это ж фича бабеля - плагины конфигов пресетов.
>>3098
>в которых, в итоге, получается сильно больше знаков, чем если бы ты писал типы в TS?
ЖСдоковые каменты по крайней мере в тело функции не протекают и ими можно назначать тип функциональным объявлениям. И проиграл от количества знаков, какая тебе нахуй разница сколько там знаков в сырцах?
>>3332
За синьором не нужно приглядывать.
За синьором не нужно приглядывать.
>>3360
Иди отсюда нахуй.
Иди отсюда нахуй.
>>3360
можно
можно
>>3295
Ну хуй знает. Взял только что рандомный проект из Гита, тоже сбилдил, залил в папку хостинга и нихуя. Все роуты при перезагрузке выдают ошибку хостингового сервиса. Может их надо ещё как-то на хостинге настраивать?
Ну хуй знает. Взял только что рандомный проект из Гита, тоже сбилдил, залил в папку хостинга и нихуя. Все роуты при перезагрузке выдают ошибку хостингового сервиса. Может их надо ещё как-то на хостинге настраивать?
>>3360
Бери да делай, хули тут на дваче спрашивать, половина в этом треде долбоебы, которые максимум alert("Hello, world!"); написали. Я знаю тех кто в 40 вкатился, главное просто не ссать, а что-то начать делать.
Бери да делай, хули тут на дваче спрашивать, половина в этом треде долбоебы, которые максимум alert("Hello, world!"); написали. Я знаю тех кто в 40 вкатился, главное просто не ссать, а что-то начать делать.
>>3245
Наверное никак, чтобы не было 404 тебе нужно в конфигах сервера прописать что все роуты идут через твою страницу (например index.html) если там nginx и у тебя нет доступа к конфигам, то земля тебе пухом, есть Apache, пробуй .htaccess конфигурировать. Сейчас у тебя скорее всего по роутам сервер ищет физически расположенный файл по этому адресу, а его нет вот и 404. А в проекте у тебя все работает потому что роуты без перезагрузки страницы и js меняет url в адресной строке.
>на бесплатный хостинг
Наверное никак, чтобы не было 404 тебе нужно в конфигах сервера прописать что все роуты идут через твою страницу (например index.html) если там nginx и у тебя нет доступа к конфигам, то земля тебе пухом, есть Apache, пробуй .htaccess конфигурировать. Сейчас у тебя скорее всего по роутам сервер ищет физически расположенный файл по этому адресу, а его нет вот и 404. А в проекте у тебя все работает потому что роуты без перезагрузки страницы и js меняет url в адресной строке.
>>3413
Ну я бы сказал, что главное не начать делоть, а продолжить
Ну я бы сказал, что главное не начать делоть, а продолжить
>>3419
Видимо так и есть. Перенаправляет на страницу, ссылка на которую записана в htaccess. Хостинг hostronavt.ru, может кто сталкивался. Как это делается в реальных проектах? Меняется конфиг сервера хостинга? Или может на хостинг заливать билд спроектированный на экспрессе, который на гет запросы будет отправлять файлы ? Или это совсем хуйня?
Видимо так и есть. Перенаправляет на страницу, ссылка на которую записана в htaccess. Хостинг hostronavt.ru, может кто сталкивался. Как это делается в реальных проектах? Меняется конфиг сервера хостинга? Или может на хостинг заливать билд спроектированный на экспрессе, который на гет запросы будет отправлять файлы ? Или это совсем хуйня?
>>3426
Обычно Apache не используется, он остался только на говнохостингах, все юзают nginx, гугли конфиги под свой стек на конкретном сервере. Телепатов тут нет.
>htaccess
>Как это делается в реальных проектах?
Обычно Apache не используется, он остался только на говнохостингах, все юзают nginx, гугли конфиги под свой стек на конкретном сервере. Телепатов тут нет.
>>3428
Ок, спасибо. Удостоверился, что не в коде ошибка.
Ок, спасибо. Удостоверился, что не в коде ошибка.
>>3428
Лол. Добавил в htaccess несколько строк
Options -MultiViews
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.html [QSA,L]
И все заработало, как надо. Хуй знает зачем пишу сюда. Может у кого-то тоже будут такие проблемы.
Лол. Добавил в htaccess несколько строк
Options -MultiViews
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.html [QSA,L]
И все заработало, как надо. Хуй знает зачем пишу сюда. Может у кого-то тоже будут такие проблемы.
>>3442
Это ты ещё со спрингом не работал, я проебался 2 дня и заменил в одной XML пару символов и оно заработало как надо
Это ты ещё со спрингом не работал, я проебался 2 дня и заменил в одной XML пару символов и оно заработало как надо
>>3428
Ты невежда и максималист.
Кто все? Я юзаю виндасервер. Апач удобней для небольших проектов на виртулках. Энжиникс удобней для дедиков.
>Обычно Apache не используется, он остался только на говнохостингах, все юзают nginx
Ты невежда и максималист.
Кто все? Я юзаю виндасервер. Апач удобней для небольших проектов на виртулках. Энжиникс удобней для дедиков.
>>3310
Ну а почему бы не попустить очередного вкатыша, который дохуя умничает? ООП в редаксе у него, просто в голосину нахуй.
Ну а почему бы не попустить очередного вкатыша, который дохуя умничает? ООП в редаксе у него, просто в голосину нахуй.
>>3475
Чем удобней то? У тебя пхп мод еще небось?
Чем удобней то? У тебя пхп мод еще небось?
>>3507
Какой метод, какого модуля? Дебич, иди доки редакса почитай. Господи, почему вкатыши такие тупые?
Какой метод, какого модуля? Дебич, иди доки редакса почитай. Господи, почему вкатыши такие тупые?
>>3574
Вкатыш, пощади. В глобал стейте нет методов. Ещё раз: пиздуй доки зубрить прежде чем нести хуйню.
Вкатыш, пощади. В глобал стейте нет методов. Ещё раз: пиздуй доки зубрить прежде чем нести хуйню.
>>3587
И глобал стейт волшебным образом меняется сам по себе. И он конечно же не объект.
>В глобал стейте нет методов.
И глобал стейт волшебным образом меняется сам по себе. И он конечно же не объект.
>>3588
ООП тут при чём? Стейт меняется через вызов функции экшн-криэйтора с последующим возвратом нового стейта через редьюсер. ООП тут вообще не при чём.
ООП тут при чём? Стейт меняется через вызов функции экшн-криэйтора с последующим возвратом нового стейта через редьюсер. ООП тут вообще не при чём.
>>3591
Не объект. Ты заебал троллить тупостью. Даже если был бы объектом, то это не про ООП.
Не объект. Ты заебал троллить тупостью. Даже если был бы объектом, то это не про ООП.
>>3591
Action Creator это функция.
Аction это объект. Но это вообще не имеет никакого отношения к ООП, так что советую принять таблетки и не пиздеть в чем не разбираешься.
Action Creator это функция.
Аction это объект. Но это вообще не имеет никакого отношения к ООП, так что советую принять таблетки и не пиздеть в чем не разбираешься.
>>3593
я хызы с чего тут спор начался, но любая функция это на самом деле частный случай объекта, так что технически вы не правы
я хызы с чего тут спор начался, но любая функция это на самом деле частный случай объекта, так что технически вы не правы
>>3616
Вот, а я всегда говорил, что фп - частный случай ООП!
Вот, а я всегда говорил, что фп - частный случай ООП!
210 Кб, 820x666Написал небольшой коммерческий интернет магазин на реукте. До сих пор ссусь проходить собесы. Есть разные вещи, которые я понимаю как работают, но когда доходит до четких ответов, начинаю скулить, мычать и нести хуйню. Что делоть? Пару раз давно проходил собесы, уходил обоссанным, флешбеки из шольных лет, где училка ставит тебя к доске, понимает, что ты нихуя не знаешь, но все равно закапывает тебя вопросами, наслаждаясь твоей беспомощностью
>>3672
Значит учи дальше, если не модешь обьяснить значит не знаешь
Значит учи дальше, если не модешь обьяснить значит не знаешь
>>0886 (OP)
Эксперты работы с апи обьясните почему если меняю ссылку на апи которое в комментариях то происходит тайперрор
https://codesandbox.io/s/bold-turing-f71jo?fontsize=14&hidenavigation=1&theme=dark
Эксперты работы с апи обьясните почему если меняю ссылку на апи которое в комментариях то происходит тайперрор
https://codesandbox.io/s/bold-turing-f71jo?fontsize=14&hidenavigation=1&theme=dark
>>3675
Значит прилетают другая структура данных, чекай через clg
Значит прилетают другая структура данных, чекай через clg
45 Кб, 512x470>>3672
Ну не знаю, попроси знакомого поиграть с тобой в ролевые игры "интервьюер - соискатель".
Ну не знаю, попроси знакомого поиграть с тобой в ролевые игры "интервьюер - соискатель".
>>3748
Не бойся на собесе физически ебать тебя никто не будет, только морально и то не везде
Не бойся на собесе физически ебать тебя никто не будет, только морально и то не везде
Кто-нибудь пользовался Zustand в проде? Есть какие-то подводные? https://www.npmjs.com/package/zustand
>>3672
Для собеса надо знать только базу - замыкания, прототипное наследование, сортировка, это стандартные вопросы на всех собесах.
Срякт и остальное что выучил можешь на пальцах объяснять. Главное еще что бы пет проект был вылизаный, заходишь на него и все блестит. Так обычно в джуны и набирают.
В любом случае лучше пробовать идти на собес, когда будешь работать - в тиме будешь расти быстрее, нежели дома.
Для собеса надо знать только базу - замыкания, прототипное наследование, сортировка, это стандартные вопросы на всех собесах.
Срякт и остальное что выучил можешь на пальцах объяснять. Главное еще что бы пет проект был вылизаный, заходишь на него и все блестит. Так обычно в джуны и набирают.
В любом случае лучше пробовать идти на собес, когда будешь работать - в тиме будешь расти быстрее, нежели дома.
>>3806
Но скорее всего у тебя не прокачаны софт скилы и социально взаимодействие. Потому что тот кто заинтересован в работе - обычно проявляет инициативу и настойчивость - в ходе беседы понимает где его минусы, интересуется как минимум чего ему не хватило для оффера, хотябы в обратном письме эйчару. После того как узнал что компания в тебе не увидела - дрочишь эти темы и дрочишь. Потом пробуешь еще раз проходить собес, можно в том же месте можно в другом.
Но скорее всего у тебя не прокачаны софт скилы и социально взаимодействие. Потому что тот кто заинтересован в работе - обычно проявляет инициативу и настойчивость - в ходе беседы понимает где его минусы, интересуется как минимум чего ему не хватило для оффера, хотябы в обратном письме эйчару. После того как узнал что компания в тебе не увидела - дрочишь эти темы и дрочишь. Потом пробуешь еще раз проходить собес, можно в том же месте можно в другом.
>>3672
Пройти не пару, а пару десятков собесов хотя бы
Пройти не пару, а пару десятков собесов хотя бы
>>3442
Всё правильно сделал, пишешь ты сюда на тот случай, если лет через пять у кого-нибудь возникнет такой же вопрос.
Всё правильно сделал, пишешь ты сюда на тот случай, если лет через пять у кого-нибудь возникнет такой же вопрос.
31 Кб, 455x316>>0886 (OP)
Сап, джигиты. Пытаюсь в редакс и появился вопрос - если я обращаюсь к стору в родительском компоненте, насколько правильно передавать стейт стора/экшены как пропсы дочернему? Или это говнокод, а в дочернем компоненте нужно еще раз подключиться к стейту?
Сап, джигиты. Пытаюсь в редакс и появился вопрос - если я обращаюсь к стору в родительском компоненте, насколько правильно передавать стейт стора/экшены как пропсы дочернему? Или это говнокод, а в дочернем компоненте нужно еще раз подключиться к стейту?
>>3932
Ксли юзаешь хуки то похуй, если юзаешь connect то можно создавать контейнер и его подключать
Ксли юзаешь хуки то похуй, если юзаешь connect то можно создавать контейнер и его подключать
>>3921
Как на самом деле тот челик расписал, ты спрашиваешь у залетного тролля. Не ведись на него.
Как на самом деле тот челик расписал, ты спрашиваешь у залетного тролля. Не ведись на него.
Вебпак нужно уметь настраивать или шаманить в нем?
Или достаточно один раз настроить и потом просто копировать его в проекты и меня src пути к файлам?
Посмотрел гайд, все настроил, все работает, лень там че то разбираться дальше.
Или достаточно один раз настроить и потом просто копировать его в проекты и меня src пути к файлам?
Посмотрел гайд, все настроил, все работает, лень там че то разбираться дальше.
>>3932
Смотря что ты хочешь сделать. Я вот пилю интернет-магазин-PWA на гатсби и у меня компоненты там двух видов - UI, которые нужны чисто чтобы рендерить UI элементы и собсно родительские, которые задают структуру и получают данные из редукса, которые потом передают в UI компоненты по надобности, а также они же диспатчат экшоны в редукс, который потом меняет стейт, запускает thunkи, которые общаются с API и так далее.
Смотря что ты хочешь сделать. Я вот пилю интернет-магазин-PWA на гатсби и у меня компоненты там двух видов - UI, которые нужны чисто чтобы рендерить UI элементы и собсно родительские, которые задают структуру и получают данные из редукса, которые потом передают в UI компоненты по надобности, а также они же диспатчат экшоны в редукс, который потом меняет стейт, запускает thunkи, которые общаются с API и так далее.
>>3947
Интересуюсь у тех кто давно в теме - нужно ли там досканально изучать его настройку, или достаточно знать как подключать файлы для компиляции и модули?
Интересуюсь у тех кто давно в теме - нужно ли там досканально изучать его настройку, или достаточно знать как подключать файлы для компиляции и модули?
>>3949
Блять, анон, странные у тебя вопросы. Вебпак, как и вообще любой фреймворк, библиотека, пакетменеджер и прочая хуйня - созданы исключительно для твоего удобства. Ты сам решаешь насколько хорошо тебе надо ознакамливаться с инструментом, который облегчает тебе жизнь. Никогда не понимал откуда у людей такая тяга устраивать себе специальные олимпиады на ровном месте.
Блять, анон, странные у тебя вопросы. Вебпак, как и вообще любой фреймворк, библиотека, пакетменеджер и прочая хуйня - созданы исключительно для твоего удобства. Ты сам решаешь насколько хорошо тебе надо ознакамливаться с инструментом, который облегчает тебе жизнь. Никогда не понимал откуда у людей такая тяга устраивать себе специальные олимпиады на ровном месте.
>>3953
КАК В РАБОТЕ ИСПОЛЬЗУЮТ ВЕБПАК, НА РАБОТЕ? В ОФИСЕ? ПОСЛЕ ВЫПИТОГО СМУЗИ?? КАК ВЕБПАК В ИДЕАЛЕ НАСТРАИВАЮТ??? КАК ВЕБПАК НАСТРАИВАЮТ ХИПСТЕРЫ БОРОДАТЫЕ В СТАРТАПАХ???? КАК ВЕБПАХ ИСПОЛЬЗУЕТСЯ В КРЕЕМНЕВОЙ ДОЛИНЕ??? КАК ВЕБПАХ НА ГАЛЕРЕ НАСТРАИВАЕТСЯ??? ВЕЗДЕ ОДИНАКОВО??? +-???? ЕСТЬ ОТЛИЧИЯ ГДЕ ТО????
так понятно?
КАК В РАБОТЕ ИСПОЛЬЗУЮТ ВЕБПАК, НА РАБОТЕ? В ОФИСЕ? ПОСЛЕ ВЫПИТОГО СМУЗИ?? КАК ВЕБПАК В ИДЕАЛЕ НАСТРАИВАЮТ??? КАК ВЕБПАК НАСТРАИВАЮТ ХИПСТЕРЫ БОРОДАТЫЕ В СТАРТАПАХ???? КАК ВЕБПАХ ИСПОЛЬЗУЕТСЯ В КРЕЕМНЕВОЙ ДОЛИНЕ??? КАК ВЕБПАХ НА ГАЛЕРЕ НАСТРАИВАЕТСЯ??? ВЕЗДЕ ОДИНАКОВО??? +-???? ЕСТЬ ОТЛИЧИЯ ГДЕ ТО????
так понятно?
>>3956
спасибо :))
спасибо :))
>>3792
Опа, ни дня без стейт менеджера в манямирке реакта.
Опа, ни дня без стейт менеджера в манямирке реакта.
Можно ли в темах стайлед компонентов хранить какие-то глобальные переменные? Т.е. у меня не будут менятся темы сами по себе. Но я просто хочу вынести туда то, что будет указываться часто, типа набора размеров шрифтов, цвета всякие и т.д. Это так делается у стайледов? Или просто создать отдельный .js файл, и оттуда по мере необходимости экспортировать нужные переменные?
>>0886 (OP)
Есть те, кто работая в одной компании становился из JS джуна мидлом? (Ну или те, кто увольнялся с джуна и шёл на мидла). Какой багаж знаний и сколько коммерческого опыта вы имели на этот момент?
Есть те, кто работая в одной компании становился из JS джуна мидлом? (Ну или те, кто увольнялся с джуна и шёл на мидла). Какой багаж знаний и сколько коммерческого опыта вы имели на этот момент?
>>4003
Перед тем как стать мидлом, 3 месяца джунил, там рост быстрый, вот до синера над попотеть
Перед тем как стать мидлом, 3 месяца джунил, там рост быстрый, вот до синера над попотеть
730 Кб, 1362x1452Кто со стайлед компонентами работал, объясните пожалуйста, а где можно собственно выбрать, какую тему в провайдер передавать? К примеру в нексте нужно обернуть в компоненте app всё компоненты, чтобы передать в них стор, потом обернуть всё в themeprovider. А из какого компонента я потом выбрать тему могу? Ведь доступ к стору я из самого app получить не могу, поскольку этот компонент в стор не обернут. А значит из всех дочерних компонентов я переключить тему не смогу. Мне кнопку же не в самом app компоненте делать? Придется еще одну обертку для провайдера делать в каком-то нижнем компоненте и туда уже передавать текущее значение для темы?
>>4025
Ну и да, в доке styled-components они просто в app компоненте делают кнопку, которой эти темы меняют. Но очевидно что в реальности в этом компоненте кнопку держать неправильно
Ну и да, в доке styled-components они просто в app компоненте делают кнопку, которой эти темы меняют. Но очевидно что в реальности в этом компоненте кнопку держать неправильно
174 Кб, 1498x1564>>4025
Ну т.е. вот к примеру, с такой оберткой я тему уже откуда угодно могу тему переключить. А как это обычно делается вообще?
Ну т.е. вот к примеру, с такой оберткой я тему уже откуда угодно могу тему переключить. А как это обычно делается вообще?
>>4020
Ну на столько ебнутых ситуаций ИРЛ не видел(если специалист не меня стек), но про грейд +- таких историй полно. Меня интересует просто различный опыт людей, который от компании к компании может быть разный.
Ну на столько ебнутых ситуаций ИРЛ не видел(если специалист не меня стек), но про грейд +- таких историй полно. Меня интересует просто различный опыт людей, который от компании к компании может быть разный.
3 Кб, 231x122>>0886 (OP)
Какого хера объект ошибки конвертится в строку, а обычный объект нет. Это баг или фича?
Какого хера объект ошибки конвертится в строку, а обычный объект нет. Это баг или фича?
794 Кб, 589x763>>4043
Ну охеть теперь.
Ну охеть теперь.
>>4040
Кто угодно может, просто читаешь поток данных из вебсокета и обновляешь что нужно
Кто угодно может, просто читаешь поток данных из вебсокета и обновляешь что нужно
>>3854
Продолжай дрочить на терминологию и думать что теперь знаешь подноготную JS, раз оказывается под капотом функции это объекты. Только на практике это тебе никак не поможет, хоть ассемблерными вызовами их назови, важно их поведение на высоком уровне.
Продолжай дрочить на терминологию и думать что теперь знаешь подноготную JS, раз оказывается под капотом функции это объекты. Только на практике это тебе никак не поможет, хоть ассемблерными вызовами их назови, важно их поведение на высоком уровне.
>>4046
Не тему. Стейт, который можно передать, чтобы эту глобал тему сменить
Не тему. Стейт, который можно передать, чтобы эту глобал тему сменить
>>4052
Очевидный Sass. Styled components замедляют и так тормознутый реакт ну и добавляют еще один слой пиздеца в кашу JS + JSX.
Очевидный Sass. Styled components замедляют и так тормознутый реакт ну и добавляют еще один слой пиздеца в кашу JS + JSX.
60 Кб, 1080x1066ЗА КАКИМ >ЯЗЫКОМ БУДУЩЕЕ???
ПЕТОН?
РИАКТ?
ДЖАВАСКРИБТ?
СИ ПЛАС ПЛАС?
ПЕТОН?
РИАКТ?
ДЖАВАСКРИБТ?
СИ ПЛАС ПЛАС?
>>4060
Спасибо, понятно теперь. А то обработчик ошибок стянул с прошлого проекта и тут внезапно ошибки посыпались.
Могли для msql библиотеки и запилить это свойство
Спасибо, понятно теперь. А то обработчик ошибок стянул с прошлого проекта и тут внезапно ошибки посыпались.
Могли для msql библиотеки и запилить это свойство
>>4061
Lol!
Пруфы? На сколько замедляют, на 0.0001 ms? Ну если тебе так важно, можно юзать linaria, тогда вообще не будут замедлять.
Просто не пишешь говнокод и ничего не будет тормозить.
Наоборот убирают слой css классов, которые загрязняют JSX.
>sass
>2021
Lol!
>Styled components замедляют
Пруфы? На сколько замедляют, на 0.0001 ms? Ну если тебе так важно, можно юзать linaria, тогда вообще не будут замедлять.
>и так тормознутый реакт
Просто не пишешь говнокод и ничего не будет тормозить.
>ну и добавляют еще один слой пиздеца в кашу JS + JSX.
Наоборот убирают слой css классов, которые загрязняют JSX.
>>4108
Менять я могу где угодно, а передать этот стейт в компонент самого высокого уровня я не могу, или не знаю как
Менять я могу где угодно, а передать этот стейт в компонент самого высокого уровня я не могу, или не знаю как
>>4061
Бестолочь, твой сасас неуправляем средствами js, в итоге ты будешь использовать и сас и инлайн стили, и кучу условного применения стилей
>Очевидный Sass
Бестолочь, твой сасас неуправляем средствами js, в итоге ты будешь использовать и сас и инлайн стили, и кучу условного применения стилей
>>4114
Будет серить в JSX data-атрибутами, в то время как мог бы аккуратно передавать пропы в стайледы
Будет серить в JSX data-атрибутами, в то время как мог бы аккуратно передавать пропы в стайледы
>>4160
У тебя могут быть почти одинаковые по сути компоненты, но которые могут менять свой внешний вид в зависимости от каких-то состойний, заглушенные кнопки, и т.п. Либо делай всё стилями, либо в стайлед компоненты передай пропсы. В первом случае у тебя будет каша css стилей и условного рендеринга. Во втором у тебя будет только один единственный стайлед компонент с пропсами
У тебя могут быть почти одинаковые по сути компоненты, но которые могут менять свой внешний вид в зависимости от каких-то состойний, заглушенные кнопки, и т.п. Либо делай всё стилями, либо в стайлед компоненты передай пропсы. В первом случае у тебя будет каша css стилей и условного рендеринга. Во втором у тебя будет только один единственный стайлед компонент с пропсами
>>4114
А стили и не должны управляться джсом. Джс управляет классами, стили применяются к ним. Styled components как идея бред. Конечно, это работает, но даже простые стили выглядит как пиздец смесь CSS и JS, страшно представить как это выглядит в больших проектах с вложенными селекторами и со сложным CSS. Стили вообще не должны никакого отношения иметь к компонентам, все что их волнует это конечные HTML селекторы.
>>4109
Поперхнулся. Как можно загрязнить то, что и так уже является грязной смесью разметки и кода?
Просто любое реактоговно даже от реакторазрабов тормозит, видимо не родились еще люди которые могут идеально писать реакт код.
А стили и не должны управляться джсом. Джс управляет классами, стили применяются к ним. Styled components как идея бред. Конечно, это работает, но даже простые стили выглядит как пиздец смесь CSS и JS, страшно представить как это выглядит в больших проектах с вложенными селекторами и со сложным CSS. Стили вообще не должны никакого отношения иметь к компонентам, все что их волнует это конечные HTML селекторы.
>>4109
>Наоборот убирают слой css классов, которые загрязняют JSX.
Поперхнулся. Как можно загрязнить то, что и так уже является грязной смесью разметки и кода?
>Просто не пишешь говнокод и ничего не будет тормозить.
Просто любое реактоговно даже от реакторазрабов тормозит, видимо не родились еще люди которые могут идеально писать реакт код.
>>4174
Ты охуеешь, но можно просто вынести твои состояния в отдельный компонент и переключать классы в нем, если очень сильно нужно. Будет точь-в-точь styled components но лучше. Но обычно даже это не нужно, и ты избавляешь себя от необходимости писать десять импортов кастомного говна, чтобы табличку сверстать, а просто пишешь html с классами.
Ты охуеешь, но можно просто вынести твои состояния в отдельный компонент и переключать классы в нем, если очень сильно нужно. Будет точь-в-точь styled components но лучше. Но обычно даже это не нужно, и ты избавляешь себя от необходимости писать десять импортов кастомного говна, чтобы табличку сверстать, а просто пишешь html с классами.
>>4182
Дурачок, а сколько у тебя будет комбинаций на 10 различный состояний? Или css-in-js уже вознесся над основами логических комбинаций и там тебе не нужно 10 модификаторов для 10 состояний, все делает зубная фея палочкой?
Дурачок, а сколько у тебя будет комбинаций на 10 различный состояний? Или css-in-js уже вознесся над основами логических комбинаций и там тебе не нужно 10 модификаторов для 10 состояний, все делает зубная фея палочкой?
>>4183
Дело тут в том, что стайледы находятся в одном месте и все, что там внутри происходит сразу же у всех на виду. А что ты там в классах с десятикратным условным рендерингом понаписал, не всегда знаешь даже ты сам.
Поздравляю, ты только что styled-components
Неудобное говно само по себе, тут даже обсуждать нечего, если только у тебя там не тудулист из 4х элементов без переиспользования
>>4185
Научись пожалуйста излагать свои мысли, я тебя с трудом понимаю. У тебя есть один стайлед компонент, внутри которого ты можешь делать все, что угодно использую все средства js. У классов говно мамонта 1000 летней давности. Предлагаешь писать отдельный класс на каждый пук, где у тебя isMobile, isDisabled, isActive, isHuiNane? Я просто не понимаю что тут вообще можно обсуждать. Может у тебя конечно там 10 захардкоженных компонентов на каждое дуновение ветра, но тут уж земля бетоном тогда
Дело тут в том, что стайледы находятся в одном месте и все, что там внутри происходит сразу же у всех на виду. А что ты там в классах с десятикратным условным рендерингом понаписал, не всегда знаешь даже ты сам.
>вынести твои состояния в отдельный компонент
Поздравляю, ты только что styled-components
>html с классами
Неудобное говно само по себе, тут даже обсуждать нечего, если только у тебя там не тудулист из 4х элементов без переиспользования
>>4185
Научись пожалуйста излагать свои мысли, я тебя с трудом понимаю. У тебя есть один стайлед компонент, внутри которого ты можешь делать все, что угодно использую все средства js. У классов говно мамонта 1000 летней давности. Предлагаешь писать отдельный класс на каждый пук, где у тебя isMobile, isDisabled, isActive, isHuiNane? Я просто не понимаю что тут вообще можно обсуждать. Может у тебя конечно там 10 захардкоженных компонентов на каждое дуновение ветра, но тут уж земля бетоном тогда
>>4177
В итоге реакт компоненты засраны этим управлением классами, в то время как в случае со стайледами просто аккуратно предаются пропы.
Выглядят как sass, только не замусорены классами и дата-атрибутами.
Если ты грядет пишешь JSX, то это твоя проблема.
У меня не тормозит, и у многих других.
>>4185
Передаешь объект с возможными состояниями как проп один раз вместо говномесива из переключений классов и всё.
>>4183
Чем лучше? Правильно, ничем. Дожили, даже в js-среде ретрограды есть, хотя казалось бы — самая динамичная среда в разработке.
> А стили и не должны управляться джсом. Джс управляет классами, стили применяются к ним
В итоге реакт компоненты засраны этим управлением классами, в то время как в случае со стайледами просто аккуратно предаются пропы.
> Styled components как идея бред. Конечно, это работает, но даже простые стили выглядит как пиздец смесь CSS и JS, страшно представить как это выглядит в больших проектах с вложенными селекторами и со сложным CSS.
Выглядят как sass, только не замусорены классами и дата-атрибутами.
> Поперхнулся. Как можно загрязнить то, что и так уже является грязной смесью разметки и кода?
Если ты грядет пишешь JSX, то это твоя проблема.
> Просто любое реактоговно даже от реакторазрабов тормозит, видимо не родились еще люди которые могут идеально писать реакт код.
У меня не тормозит, и у многих других.
>>4185
Передаешь объект с возможными состояниями как проп один раз вместо говномесива из переключений классов и всё.
>>4183
Чем лучше? Правильно, ничем. Дожили, даже в js-среде ретрограды есть, хотя казалось бы — самая динамичная среда в разработке.
>>4197
Ну так не пиши классы с десятикратным условным рендерингом, поехавший. sass тут при чем?
Один на каждый пук в приложении и все стили с нуля пишешь? Или может они все-таки что-то между собой имеют общее? Если второе, то не один.
>>4202
А в кастомный компонент ты объект с состояниями передать не можешь или как?
>А что ты там в классах с десятикратным условным рендерингом понаписал
Ну так не пиши классы с десятикратным условным рендерингом, поехавший. sass тут при чем?
>У тебя есть один стайлед компонент
Один на каждый пук в приложении и все стили с нуля пишешь? Или может они все-таки что-то между собой имеют общее? Если второе, то не один.
>>4202
>Передаешь объект с возможными состояниями как проп один раз вместо говномесива из переключений классов и всё.
А в кастомный компонент ты объект с состояниями передать не можешь или как?
>>4207
Каждый span в реакт компонент что ли оборачивать? И там разводить дрисню из переключения классов, когда я могу одной строчкой это через стайледы сделать?
В общем, хотелось бы увидеть реальные ощутимые примущества сасс перед стайледами. Но вот что-то ни разу никто не выложил пример, где было бы видно в коде, что сасс лучше стайледов.
> А в кастомный компонент ты объект с состояниями передать не можешь или как?
Каждый span в реакт компонент что ли оборачивать? И там разводить дрисню из переключения классов, когда я могу одной строчкой это через стайледы сделать?
В общем, хотелось бы увидеть реальные ощутимые примущества сасс перед стайледами. Но вот что-то ни разу никто не выложил пример, где было бы видно в коде, что сасс лучше стайледов.
>>4197
Не поверишь, селекторы по классам состояний тоже в одном месте находятся, в скоупе базового класса.
>Дело тут в том, что стайледы находятся в одном месте и все, что там внутри происходит сразу же у всех на виду. А что ты там в классах с десятикратным условным рендерингом понаписал, не всегда знаешь даже ты сам.
Не поверишь, селекторы по классам состояний тоже в одном месте находятся, в скоупе базового класса.
>>4209
Тебе нужно переключать классы у каждого span'а в приложении? Если нет, то попробуй другую аргументацию, эта жиденьким стекает по ляжке.
Тебе нужно переключать классы у каждого span'а в приложении? Если нет, то попробуй другую аргументацию, эта жиденьким стекает по ляжке.
>>4209
Как будто говно, которое ты импортируешь свой стайлед, не состоит из дрисни ифов.
Странно, что ты тоже нихуя не выложил, а доказывать тебе должны тебе.
>одной строчкой это через стайледы сделать
Как будто говно, которое ты импортируешь свой стайлед, не состоит из дрисни ифов.
>Но вот что-то ни разу никто не выложил пример, где было бы видно в коде, что сасс лучше стайледов.
Странно, что ты тоже нихуя не выложил, а доказывать тебе должны тебе.
>>4210
Ну теперь стал понятен уровень дискуссии. И вот такую срань ты предлагаешь в качестве альтернативы стайледам? Это так верстальщики свой загон охранять решили? Ну тогда понятно
>селекторы по классам состояний тоже в одном месте находятся, в скоупе базового класса.
Ну теперь стал понятен уровень дискуссии. И вот такую срань ты предлагаешь в качестве альтернативы стайледам? Это так верстальщики свой загон охранять решили? Ну тогда понятно
>>4209
Нет дружок, речь как раз о том, что сасс делает все то же самое, что делает любая js-дрисня для стилей, но выглядит лучше, воспринимается легче, работает быстрее и понимается любым человеком, знакомым с азами css-html. Так что показывать и доказывать преимущество js-дрисни на сассом должен именно ты или другие подобные тебе, а не наоборот. Пока этих преимуществ не видно.
>хотелось бы увидеть реальные ощутимые примущества сасс перед стайледами
Нет дружок, речь как раз о том, что сасс делает все то же самое, что делает любая js-дрисня для стилей, но выглядит лучше, воспринимается легче, работает быстрее и понимается любым человеком, знакомым с азами css-html. Так что показывать и доказывать преимущество js-дрисни на сассом должен именно ты или другие подобные тебе, а не наоборот. Пока этих преимуществ не видно.
>>4223
Твоя альтернатива - хранить такую же срань в отдельном модуле, заместо отдельного файла стилей.
Неплохая боль неосилятора CSS, языка для макак между прочим. Интересно конечно про загоны слушать от жсдебила, который даже свою маму в скрипте хранит.
>Ну теперь стал понятен уровень дискуссии. И вот такую срань ты предлагаешь в качестве альтернативы стайледам?
Твоя альтернатива - хранить такую же срань в отдельном модуле, заместо отдельного файла стилей.
>Это так верстальщики свой загон охранять решили?
Неплохая боль неосилятора CSS, языка для макак между прочим. Интересно конечно про загоны слушать от жсдебила, который даже свою маму в скрипте хранит.
>>4224
Толстота полилась. Покажи компонент кнопки, который может иметь 3 разных стиля, 2 разных варианта для мобильной и десктопной версии, состояние активно и заблокировано. И чтобы в любой момент ты мог 3 изначальных стиля расширить. Мне страшно представить какое количество говна ты туда понапишешь своим сасасом, который ты сам не сможешь разобрать уже через полчаса после написания.
Толстота полилась. Покажи компонент кнопки, который может иметь 3 разных стиля, 2 разных варианта для мобильной и десктопной версии, состояние активно и заблокировано. И чтобы в любой момент ты мог 3 изначальных стиля расширить. Мне страшно представить какое количество говна ты туда понапишешь своим сасасом, который ты сам не сможешь разобрать уже через полчаса после написания.
>>4226
Ну тут уже в шепот, как будто бы я не верстал никогда сложных интерфейсов, и решил на стайледы перейти просто из вредности тебе, хуя маняутешения сразу нашлись
>неосилятора CSS
Ну тут уже в шепот, как будто бы я не верстал никогда сложных интерфейсов, и решил на стайледы перейти просто из вредности тебе, хуя маняутешения сразу нашлись
14 Кб, 348x481>>4228
Держи, дурачок. Покажешь свою js дрисню или как обычно пукнешь и сольешься?
Держи, дурачок. Покажешь свою js дрисню или как обычно пукнешь и сольешься?
>>4242
Ну вот о том и речь, теперь подумай как это выглядит на самой кнопке, где у тебя будет миллиард условий для рендера отдельных классов, вместо тех же самых условий в самих полях стилей которые видны сразу. Ты ушел не так далеко от того, чтобы сделать это еще удобнее. 3 вида кнопки, это изначальные стили, а уже к ним применяется состояние активно или заблокировано, в итоге тебе все равно нужно будет создавать отдельный компонент, который еще и стили будет подгружать, вместо того чтобы этот компонент изначально на стайлед компонентах и сделать чел пчел пчелибас, тут просто не может быть никакого смсысла в добавлении стилей к тому, что изначально стилями можно описать
Ну вот о том и речь, теперь подумай как это выглядит на самой кнопке, где у тебя будет миллиард условий для рендера отдельных классов, вместо тех же самых условий в самих полях стилей которые видны сразу. Ты ушел не так далеко от того, чтобы сделать это еще удобнее. 3 вида кнопки, это изначальные стили, а уже к ним применяется состояние активно или заблокировано, в итоге тебе все равно нужно будет создавать отдельный компонент, который еще и стили будет подгружать, вместо того чтобы этот компонент изначально на стайлед компонентах и сделать чел пчел пчелибас, тут просто не может быть никакого смсысла в добавлении стилей к тому, что изначально стилями можно описать
>>4244
Не вижу твоего варианта, видимо не прикрепилось. Попробуй еще раз.
<button className="btn btn-primary"/>
Создам я его только тогда, когда он мне понадобится, не раньше. У меня же нет невынимаемой sc-затычки в жопе, которая требует кастомного комопнента на любой пук.
Не вижу твоего варианта, видимо не прикрепилось. Попробуй еще раз.
>как это выглядит на самой кнопке
<button className="btn btn-primary"/>
>в итоге тебе все равно нужно будет создавать отдельный компонент
Создам я его только тогда, когда он мне понадобится, не раньше. У меня же нет невынимаемой sc-затычки в жопе, которая требует кастомного комопнента на любой пук.
>>4251
То, что ты мне показал, вообще к изначальному условию, которое я описал не применимо. Очень похоже на то, что ты просто верстальщик, и не хочешь терять своё место, либо учить js
Даже в этом простейшем примере у тебя уже на первой же итерации начала выходить дристня. Объясни мне, а лучше сначала себе, зачем в этой цепочке нужна прослойки из css классов?
Я твоего тоже не увидел, но забавно то, что даже в твоём урезанном до предела примере всё уже выглядит как говно. Представь, что у тебя btn-primary1, btn-primary2, btn-primary3, для каждой active, disabled, и для каждого варианта wide/mobile. И попробуй убедить себя в том, что классами это можно сделать элегантнее и читабельнее. И это при том, что тебе все равно нужно будет создавать компонент. В итоге ты сделаешь бессмысленную прослойку видимо только из вредности мне?
То, что ты мне показал, вообще к изначальному условию, которое я описал не применимо. Очень похоже на то, что ты просто верстальщик, и не хочешь терять своё место, либо учить js
><button className="btn btn-primary"/>
Даже в этом простейшем примере у тебя уже на первой же итерации начала выходить дристня. Объясни мне, а лучше сначала себе, зачем в этой цепочке нужна прослойки из css классов?
>Не вижу твоего варианта, видимо не прикрепилось. Попробуй еще раз.
Я твоего тоже не увидел, но забавно то, что даже в твоём урезанном до предела примере всё уже выглядит как говно. Представь, что у тебя btn-primary1, btn-primary2, btn-primary3, для каждой active, disabled, и для каждого варианта wide/mobile. И попробуй убедить себя в том, что классами это можно сделать элегантнее и читабельнее. И это при том, что тебе все равно нужно будет создавать компонент. В итоге ты сделаешь бессмысленную прослойку видимо только из вредности мне?
>>4258
Шизик, твое начальное условие описанное тобой же, это: 3 разных стиля, 2 варианта для мобильной и десктопной версии и два состояния. Все соблюдены до точки. Что ты там нафантазировал у себя в голове я прочитать не могу, только то, что написано текстом.
Ну наверное потому что просто кнопка и кнопка с primary стилем - это разные кнопки и это стандартная практика шеринга стилей, чтобы их не дублировать несколько раз в итоговом коде? Лично ты можешь сделать миксин кнопки и включать его внутри btn-danger/btn-primary, тогда даже btn писать будет не нужно, если готов заплатить за это несколько килобайтов. Разрешаю.
Представить не могу, если не дебил с цифрами в классах. То, как мои кнопки будут выглядеть, я уже написал:
<button className="btn btn-primary" disabled={isDisabled}/>
<buttom className="btn btn-danger" disabled={isDisabled}/>
Расскажешь, почему для это вдруг "нечитабельно" и как js-дрисня сделает это лучше? И все еще жду пример твоей js-дрисни, а то в воздух ты пердел-пердел о конкретике, а в итоге сливаешься без примеров.
>То, что ты мне показал, вообще к изначальному условию, которое я описал не применимо
Шизик, твое начальное условие описанное тобой же, это: 3 разных стиля, 2 варианта для мобильной и десктопной версии и два состояния. Все соблюдены до точки. Что ты там нафантазировал у себя в голове я прочитать не могу, только то, что написано текстом.
>Объясни мне, а лучше сначала себе, зачем в этой цепочке нужна прослойки из css классов?
Ну наверное потому что просто кнопка и кнопка с primary стилем - это разные кнопки и это стандартная практика шеринга стилей, чтобы их не дублировать несколько раз в итоговом коде? Лично ты можешь сделать миксин кнопки и включать его внутри btn-danger/btn-primary, тогда даже btn писать будет не нужно, если готов заплатить за это несколько килобайтов. Разрешаю.
>Представь, что у тебя btn-primary1, btn-primary2, btn-primary3
Представить не могу, если не дебил с цифрами в классах. То, как мои кнопки будут выглядеть, я уже написал:
<button className="btn btn-primary" disabled={isDisabled}/>
<buttom className="btn btn-danger" disabled={isDisabled}/>
Расскажешь, почему для это вдруг "нечитабельно" и как js-дрисня сделает это лучше? И все еще жду пример твоей js-дрисни, а то в воздух ты пердел-пердел о конкретике, а в итоге сливаешься без примеров.
>>2889
Пробуй без статики и с меньшим количеством зависимостей
https://stackblitz.com/edit/typescript-kpxz6k?file=index.ts
Пробуй без статики и с меньшим количеством зависимостей
https://stackblitz.com/edit/typescript-kpxz6k?file=index.ts
>>4214
Сначала дай хоть один внятный аргумент чем архаичный sass лучше стайледов.
>>4215
Ничего никуда не импортируется, пропы в стайледы прикидываются как в обычных реакт компонентах и дрисни из ифов нигде нет. Только однострочные тернарники.
Первым было утверждение, что стайледы говно, вот и доказывайте, сасс-шизы
>>4224
Но стайлдеы могут всё то же, что и сасс, но при этом больше из-за возможней js. Стайледы выглядят красивее и легче воспринимаются, потому что в них нет дрисни из css-классов, и в них нет ничего сложного, из понимает любой человек, который уже работает с реактом.
Сначала дай хоть один внятный аргумент чем архаичный sass лучше стайледов.
>>4215
> Как будто говно, которое ты импортируешь свой стайлед, не состоит из дрисни ифов.
Ничего никуда не импортируется, пропы в стайледы прикидываются как в обычных реакт компонентах и дрисни из ифов нигде нет. Только однострочные тернарники.
> Странно, что ты тоже нихуя не выложил, а доказывать тебе должны тебе.
Первым было утверждение, что стайледы говно, вот и доказывайте, сасс-шизы
>>4224
> Нет дружок, речь как раз о том, что сасс делает все то же самое, что делает любая js-дрисня для стилей, но выглядит лучше, воспринимается легче, работает быстрее и понимается любым человеком, знакомым с азами css-html
Но стайлдеы могут всё то же, что и сасс, но при этом больше из-за возможней js. Стайледы выглядят красивее и легче воспринимаются, потому что в них нет дрисни из css-классов, и в них нет ничего сложного, из понимает любой человек, который уже работает с реактом.
>>4299
Каких возможностей тебе в сассе не хватает, подскажи?
Перетолстил.
>>4302
Ну вот видишь, уже выглядит как дрисня с магическим кастомным DSL и у этих людей хватает наглости кукарекать про "неявность" сасса, а теперь возьми стандартный реакт компонент с десятком разных элементов. Будешь каждый раз хуячить 10-строчные импорты своих кнопок, таблиц, лейаутов?
>Но стайлдеы могут всё то же, что и сасс, но при этом больше из-за возможней js
Каких возможностей тебе в сассе не хватает, подскажи?
> Стайледы выглядят красивее и легче воспринимаются
Перетолстил.
>>4302
Ну вот видишь, уже выглядит как дрисня с магическим кастомным DSL и у этих людей хватает наглости кукарекать про "неявность" сасса, а теперь возьми стандартный реакт компонент с десятком разных элементов. Будешь каждый раз хуячить 10-строчные импорты своих кнопок, таблиц, лейаутов?
255 Кб, 512x512>>4302
Блен. Не обессудь пчел. Как по мне это всё слишком нагромождёно смотрится и читается. И это я так понял маленькая простыня, а если большой компонент будет...
мимо
Блен. Не обессудь пчел. Как по мне это всё слишком нагромождёно смотрится и читается. И это я так понял маленькая простыня, а если большой компонент будет...
мимо
44 Кб, 603x482>>4342
Скрин не прикрепился. Фикс
Скрин не прикрепился. Фикс
>>4342
По объему не больше sass, так что не вижу нагромождения. Ну и читается не сложнее, как по мне, тем более подсветка синтаксиса в vscode лучше, чем в codesandbox.
Огромный компонент будет не больше, чем sass, но удобнее. Выше в треде был пример с sass, там не меньше объём.
>>4337
Возможностей js, очевидно.
Импорт всего лишь несколько строк в начале файла занимают, это вообще не мешает, в отличие от засирания jsx css-классами и логикой из переключения. Но ещё одно преимущество стайледов в том, что локальные компоненты можно объявлять прямо внутри реакт компонента, а импорты будут только для общих компонентов типа кнопок.
По объему не больше sass, так что не вижу нагромождения. Ну и читается не сложнее, как по мне, тем более подсветка синтаксиса в vscode лучше, чем в codesandbox.
Огромный компонент будет не больше, чем sass, но удобнее. Выше в треде был пример с sass, там не меньше объём.
>>4337
> Каких возможностей тебе в сассе не хватает, подскажи?
Возможностей js, очевидно.
> Будешь каждый раз хуячить 10-строчные импорты своих кнопок, таблиц, лейаутов?
Импорт всего лишь несколько строк в начале файла занимают, это вообще не мешает, в отличие от засирания jsx css-классами и логикой из переключения. Но ещё одно преимущество стайледов в том, что локальные компоненты можно объявлять прямо внутри реакт компонента, а импорты будут только для общих компонентов типа кнопок.
>>4350
Попробовал этот стайлед, если размещать стили в самом компоненте приходится туда сюда скролить постоянно, хуй знает с другой стороны удобно что все в одном месте, прям пиздец хуй знает че делать
Попробовал этот стайлед, если размещать стили в самом компоненте приходится туда сюда скролить постоянно, хуй знает с другой стороны удобно что все в одном месте, прям пиздец хуй знает че делать
>>4350
Каких? Одну назовешь?
То есть засирание импортами говна тебе не мешает, а обычные html-классы вдруг мешают? Ты поехавший?
Не засирай, вынеси логику переключения в отдельный компонент, прямо как выносишь любую другую. Зачем тебе для этого ебаный sc?
Это называется "антипаттерн" и "говнокод", а не "преимущество".
>Возможностей js, очевидно.
Каких? Одну назовешь?
>в отличие от засирания jsx css-классами
То есть засирание импортами говна тебе не мешает, а обычные html-классы вдруг мешают? Ты поехавший?
>и логикой из переключения
Не засирай, вынеси логику переключения в отдельный компонент, прямо как выносишь любую другую. Зачем тебе для этого ебаный sc?
>Но ещё одно преимущество стайледов в том, что локальные компоненты можно объявлять прямо внутри реакт компонента
Это называется "антипаттерн" и "говнокод", а не "преимущество".
>>0886 (OP)
Нужно получить JSON с данными с сервера. Есть условие, что в респонсе должен быть ответ со значением {stop: true}, тогда типа все ок, JSON готов.
Я решил поиграться в браузере - вбил строку с реквестом, и смотрю в консоле респонс, там stop всегда false (пробовал отправлять реквест несколько раз снова и снова, в итоге сервер просто обрубил меня).
Это как - в промисе ждать, пока в респонсе тру не будет, не резолвить? Или другой способ? Почему в браузере не получается?
Нужно получить JSON с данными с сервера. Есть условие, что в респонсе должен быть ответ со значением {stop: true}, тогда типа все ок, JSON готов.
Я решил поиграться в браузере - вбил строку с реквестом, и смотрю в консоле респонс, там stop всегда false (пробовал отправлять реквест несколько раз снова и снова, в итоге сервер просто обрубил меня).
Это как - в промисе ждать, пока в респонсе тру не будет, не резолвить? Или другой способ? Почему в браузере не получается?
>>4342
Чел пчелибас, то, что ты видешь это буквально весь код. То, что высрал сасасозащитник, это только css код, который уже выглядит хуже и каждый пук еще и свой УЖАСНЫЙ НЕНУЖНЫЙ JS КОД будет просить, но этого он отчаяно не хочеть видеть и не хочет показывать
Чел пчелибас, то, что ты видешь это буквально весь код. То, что высрал сасасозащитник, это только css код, который уже выглядит хуже и каждый пук еще и свой УЖАСНЫЙ НЕНУЖНЫЙ JS КОД будет просить, но этого он отчаяно не хочеть видеть и не хочет показывать
551 Кб, 733x678Пацаны, чет подзабыл, подскажите:
Когда через скрипты меняем например текст в html документе.
Где хранится этот измененный DOM ? В кэше?
Типо если обновить страницу, то HTML страница возвращается к стандартному DOM который был прописан в HTML до выполнения скрипта. Измененный DOM типа временный получается.
Когда через скрипты меняем например текст в html документе.
Где хранится этот измененный DOM ? В кэше?
Типо если обновить страницу, то HTML страница возвращается к стандартному DOM который был прописан в HTML до выполнения скрипта. Измененный DOM типа временный получается.
Как бы мне SASS не нравился, но он пососет, когда надо будет делать стилизацию вложенных компонентов. В SASS амперсанд селектор нельзя ставить не в начале селектора, а в SC можно (&&). Это нужно для правильной семантики, не всегда родительский компонент должен диктовать как выглядит дочерний. Также CSS-in-JS позволяет лучше отслеживать модули и их импорты, что упрощает рефакторинг и переход к имплементации по клику в IDE. В SC ты можешь импортировать компонент и вставить в литерал вместо CSS класса компонента, что не позволяет оставить старое имя класса, после его переименования.
Все, что по факту предъявляют SASS-шизы в треде - импакт по производительности. Который на деле является микроскопическим, если ты делаешь все правильно и не дрючишь стили 60 раз в секунду. А если ты настроишь SSR, то этот импакт вообще устремится к нулю.
Про отвал всего приложения на SC: приложение надо тестировать и ошибки оборачивать в ErrorBoundary
Все, что по факту предъявляют SASS-шизы в треде - импакт по производительности. Который на деле является микроскопическим, если ты делаешь все правильно и не дрючишь стили 60 раз в секунду. А если ты настроишь SSR, то этот импакт вообще устремится к нулю.
Про отвал всего приложения на SC: приложение надо тестировать и ошибки оборачивать в ErrorBoundary
Написал свой онлайн магазин, типо вайлдбериз или озона. Как думаете на IPO уже щас подавать? Или еще подождать лучше?
>>4627
Думаю сейчас рынок не готов к такому, ты опередил своё время. Нужно выждать момент
Думаю сейчас рынок не готов к такому, ты опередил своё время. Нужно выждать момент
>>4627
Тебе самому как, нравится, что у тебя от селекта айтемов грид прыгает будто у него эпилепсия?
Тебе самому как, нравится, что у тебя от селекта айтемов грид прыгает будто у него эпилепсия?
>>4666
можешь border заменить на box-shadow, он не будет ничего сдвигать. Если игнорировать сам факт того, что ты делаешь какую-то хуйню. Ну или просто использовать гриды
можешь border заменить на box-shadow, он не будет ничего сдвигать. Если игнорировать сам факт того, что ты делаешь какую-то хуйню. Ну или просто использовать гриды
>>4353
Уже не раз назвал возможность передавать пропсы, например, или темизация, но ты копротивляешься ради архаичного пердолинга с классами, дата-атрибутами и написанием большего количества кода просто потому что у тебя иррациональная неприязнь к новым, более функциональным инструментам. Сасс-шизы это прямо неолуддиты из мира фронтенд разработки.
Импорты во-первых ничего не засирают, их вообще не видно потому что они в самом начале файла, а вот css-дрисня гадит прямо посреди jsx.
Зачем что-то куда-то выносить и засирать проект лишними файлами, когда я могу в стайледах аккуратно, красиво и удобно а одну или пару строк это сделать?
Ты скозал? Single file components в vue тоже антипаттерн? Лол. Я для тебя ещё раз повторю: внутри реакт компонента иногда люди могут оставлять локальные стайледы. Common вещи вносятся в отдельные файлы, очевидно. Но импорты — это последнее, что засирает код, потому что их тупо не видно на экране во время работы.
> Каких? Одну назовешь?
Уже не раз назвал возможность передавать пропсы, например, или темизация, но ты копротивляешься ради архаичного пердолинга с классами, дата-атрибутами и написанием большего количества кода просто потому что у тебя иррациональная неприязнь к новым, более функциональным инструментам. Сасс-шизы это прямо неолуддиты из мира фронтенд разработки.
> То есть засирание импортами говна тебе не мешает, а обычные html-классы вдруг мешают? Ты поехавший?
Импорты во-первых ничего не засирают, их вообще не видно потому что они в самом начале файла, а вот css-дрисня гадит прямо посреди jsx.
> Не засирай, вынеси логику переключения в отдельный компонент, прямо как выносишь любую другую.
Зачем что-то куда-то выносить и засирать проект лишними файлами, когда я могу в стайледах аккуратно, красиво и удобно а одну или пару строк это сделать?
> Это называется "антипаттерн" и "говнокод", а не "преимущество".
Ты скозал? Single file components в vue тоже антипаттерн? Лол. Я для тебя ещё раз повторю: внутри реакт компонента иногда люди могут оставлять локальные стайледы. Common вещи вносятся в отдельные файлы, очевидно. Но импорты — это последнее, что засирает код, потому что их тупо не видно на экране во время работы.
>>4434
Бампану вопрос разок.
Бампану вопрос разок.
>>4686
Спасибо! Хорошего дня!
Спасибо! Хорошего дня!
132 Кб, 756x576Аноны, подскажите как убрать эту гифку и текст из программы! Спасибо.
>>4555
sass у тебя эту возможность не отнимает, хочешь - делай логику и передавай. В 99% случаев тебе так и так нужно эту логику писать, потому что это рабочая логика приложения, а стили просто приходятся сверху дополнением, как и должны. Схуев ли ты решил, что завязывать стилизацию и рабочую логику переключения стейта в одно месиво это хорошая идея - большой вопрос.
Что тебе мешает сделать темизацию css-методами вместо ре-рендеринга всего приложения нахуй?
Но больше кода пишут как раз sc-шизы, потому что выкидывают в окно готовые инструменты(html-классы) и пердолятся со своим инлайн говном и кастомными компонентами.
Охуительные истории, 30 строчек импортов - это заебись, они в начале файла и их не видно. Представляю твои файлы.
См. выше. Логика переключения стейтов - это рабочая логика, и писать для нее "лишние файлы" ты будешь так и так. А если не будешь, то инлайн добавить класс по условию нихуя не проблема.
Да, я скозал. Что там в vue не ебу, но хуярить sc внутри комопнента - это точно то же самое, что хуярить инлайн-стили вместо классов. Почему это плохо и говнокод, можешь спросить в 2010 году, еще тогда все выяснили.
>возможность передавать пропсы
sass у тебя эту возможность не отнимает, хочешь - делай логику и передавай. В 99% случаев тебе так и так нужно эту логику писать, потому что это рабочая логика приложения, а стили просто приходятся сверху дополнением, как и должны. Схуев ли ты решил, что завязывать стилизацию и рабочую логику переключения стейта в одно месиво это хорошая идея - большой вопрос.
>или темизация
Что тебе мешает сделать темизацию css-методами вместо ре-рендеринга всего приложения нахуй?
>написанием большего количества кода
Но больше кода пишут как раз sc-шизы, потому что выкидывают в окно готовые инструменты(html-классы) и пердолятся со своим инлайн говном и кастомными компонентами.
>их вообще не видно потому что они в самом начале файла
Охуительные истории, 30 строчек импортов - это заебись, они в начале файла и их не видно. Представляю твои файлы.
> Зачем что-то куда-то выносить и засирать проект лишними файлами
См. выше. Логика переключения стейтов - это рабочая логика, и писать для нее "лишние файлы" ты будешь так и так. А если не будешь, то инлайн добавить класс по условию нихуя не проблема.
>Ты скозал? Single file components в vue тоже антипаттерн
Да, я скозал. Что там в vue не ебу, но хуярить sc внутри комопнента - это точно то же самое, что хуярить инлайн-стили вместо классов. Почему это плохо и говнокод, можешь спросить в 2010 году, еще тогда все выяснили.
110 Кб, 806x1092>>4782
Во .vue файлах пик, scoped аттрибут изменяет любой селектор и добавляет доп. условие, чтобы в других компонентах/дом элементах с таким классом ничего не применялось. Ну еще можно сделать <style lang="scss"> и у тебя сасс работает (да что угодно, главное чтобы вебпак понял о чем ты), импортируешь свои миксины и дрочишься. И еще можно несколько <style> тагов, например хочешь прямо из компонента срать в глобальные стили. Короче хз нахуя я это пишу но лично мне вью очень нравится тем что его можно постепенно очень хорошо внедрять в уже существующее легаси говно.
мимо
>Что там в vue не ебу
Во .vue файлах пик, scoped аттрибут изменяет любой селектор и добавляет доп. условие, чтобы в других компонентах/дом элементах с таким классом ничего не применялось. Ну еще можно сделать <style lang="scss"> и у тебя сасс работает (да что угодно, главное чтобы вебпак понял о чем ты), импортируешь свои миксины и дрочишься. И еще можно несколько <style> тагов, например хочешь прямо из компонента срать в глобальные стили. Короче хз нахуя я это пишу но лично мне вью очень нравится тем что его можно постепенно очень хорошо внедрять в уже существующее легаси говно.
мимо
Подскажите такой вопрос. Есть сервер простой на экспрессе. Где хранить в нем всякие api keys и прочие приватные данные? Установить dotenv, и через него получать доступ к моему созданному файлу .env с переменными? А как в продакшене это будет работать ? Я сбилджу, мои переменные из моего файла закодируются и у приложения к ним будет доступ без dotenv?
>>4850
Ну правильно я понимаю, что дотенв - пакет только для того что бы можно было из созданного мною файла брать переменные для разработки ? А в проде мои переменные подтянутся в окружение.
Ну правильно я понимаю, что дотенв - пакет только для того что бы можно было из созданного мною файла брать переменные для разработки ? А в проде мои переменные подтянутся в окружение.
>>4849
1) Создаешь .env файл, пишешь в него все свои ключи, добавляешь этот файл в .gitignore
2) Создаешь .env.example файл пишешь в него все те же самые ключи, только без секретных значений, чтобы можно было окружение воспроизвести на другой машине или другому разработчику без заебов. Коммитишь этот файл и обновляешь по мере надобности.
3) Добавляешь в README как часть сетапа строчку `cp .env.example .env`
4) На любом новом сервере с проектом просто выполняешь команду выше и заполняешь все ключи, либо проставляешь эти ключи в ENV переменные контейнера, если у тебя какой-нибудь докер, а файл оставляешь пустым.
1) Создаешь .env файл, пишешь в него все свои ключи, добавляешь этот файл в .gitignore
2) Создаешь .env.example файл пишешь в него все те же самые ключи, только без секретных значений, чтобы можно было окружение воспроизвести на другой машине или другому разработчику без заебов. Коммитишь этот файл и обновляешь по мере надобности.
3) Добавляешь в README как часть сетапа строчку `cp .env.example .env`
4) На любом новом сервере с проектом просто выполняешь команду выше и заполняешь все ключи, либо проставляешь эти ключи в ENV переменные контейнера, если у тебя какой-нибудь докер, а файл оставляешь пустым.
>>4434
И что, вечно будешь ждать? Может сервер его не пришлет. Нужен лимит времени, setTimeout, установить какой-либо.
>должен быть ответ со значением {stop: true}
И что, вечно будешь ждать? Может сервер его не пришлет. Нужен лимит времени, setTimeout, установить какой-либо.
>>4908
Ок. Спасибо.
Ок. Спасибо.
Начал проходить эпический курс по js на 100 часов.
Так вот в конце курса проходим реакт. А в начале щупаем es6 и пишем свою библиотек по типу jquery, мол что бы понимать как классы работают и вообще библиотеки. Пока сидели разбирали как jquery работает я чуть не охуел от перегрузки, эта тема действительно нужна или можно скипать и учить реакт?
Так вот в конце курса проходим реакт. А в начале щупаем es6 и пишем свою библиотек по типу jquery, мол что бы понимать как классы работают и вообще библиотеки. Пока сидели разбирали как jquery работает я чуть не охуел от перегрузки, эта тема действительно нужна или можно скипать и учить реакт?
>>4979
Можно в целом обучение скипать и работать идти.
Да и чего воемя тратить? Иди сразу зарплату получать.
Можно в целом обучение скипать и работать идти.
Да и чего воемя тратить? Иди сразу зарплату получать.
Какие иде еще можете посоветовать кроме ВСК и ВЕбшторма для реакта+тс? В ВСК вроде бы неплохо, но в целом интерфейс какой-то тормознутый, я хз. Вебштормом пользуюсь полгода, даже платную версию купил, в целом все работает круто, но как доходит до каких-то нестандартных фич, он шлет тебя нахуй и отправляет в загон багрепортов, которые там годами висят.
>>4998
Там их 4, каждый продолжение предыдущего.
Там их 4, каждый продолжение предыдущего.
Сейчас смотрю курсы htmlacademy по html, у кого-нибудь есть весь html и css файл по сайту barbershop?
Курс невозможно смотреть, много воды + эти два деятеля не печатают код сами, а показывают какие-то картиночки.
КАРТИНОЧКИ, БЛЯДЬ!!!
P.S. Чьи курсы по html/js вы можете посоветовать?
Курс невозможно смотреть, много воды + эти два деятеля не печатают код сами, а показывают какие-то картиночки.
КАРТИНОЧКИ, БЛЯДЬ!!!
P.S. Чьи курсы по html/js вы можете посоветовать?
>>5007
Нормальные у академии курсы. Весь макет лежит в гугле, на первой строчке, с приставкой git
петриченко нормально еще за html css поясняет, на рутрекере валяется
Нормальные у академии курсы. Весь макет лежит в гугле, на первой строчке, с приставкой git
петриченко нормально еще за html css поясняет, на рутрекере валяется
Как правильнее юзать редакс?
const add = () =>{
dispatch({type: actionTypes.ADD_TO_CART, payload: {id:id, name:data.Name, price:data.Price} })
}
или создать отдельный файл для экшенов, а потом просто написать
const add = () =>{
dispatch(addToCart(id,data)
}
const add = () =>{
dispatch({type: actionTypes.ADD_TO_CART, payload: {id:id, name:data.Name, price:data.Price} })
}
или создать отдельный файл для экшенов, а потом просто написать
const add = () =>{
dispatch(addToCart(id,data)
}
>>5014
это
redux-toolkit поставь, чтобы первого варианта даже как варианта не было
>создать отдельный файл для экшенов, а потом просто написать
это
redux-toolkit поставь, чтобы первого варианта даже как варианта не было
>>5017
ну первый пик про версточку которая типа на работе учится и dom, к которому настоящие реакт-интеграторы не притрагиваются
Знать конечно это все нужно, но ты же уснешь
второй - это ооп за 24 часа ы, объект - значит ооп)) и ajax через jquery. jsonp хорош для кругозора, cors на работе почитаешь
третий неплох, но вот эти декораторы через бабель поняты не будут. mobx для начала тоже сомнителен, надо сразу погружать в редакс, чтобы spacex dragon завидовал жопной тяге, но это субъективное
4 был бы норм, если бы побольше хуков и поменьше классов, ну и смотря что там в разделе про формы
Все эти полифилы для фетча попахивают 2018. Ну и ни слова про тайпскрипт.
ну первый пик про версточку которая типа на работе учится и dom, к которому настоящие реакт-интеграторы не притрагиваются
Знать конечно это все нужно, но ты же уснешь
второй - это ооп за 24 часа ы, объект - значит ооп)) и ajax через jquery. jsonp хорош для кругозора, cors на работе почитаешь
третий неплох, но вот эти декораторы через бабель поняты не будут. mobx для начала тоже сомнителен, надо сразу погружать в редакс, чтобы spacex dragon завидовал жопной тяге, но это субъективное
4 был бы норм, если бы побольше хуков и поменьше классов, ну и смотря что там в разделе про формы
Все эти полифилы для фетча попахивают 2018. Ну и ни слова про тайпскрипт.
>>5027
Это все так, для общего кругозора, беру так сказать колличеством.
А качеством буду брать на курсе буры, там по реакту полный порядок.
Спасибо анончик, хорошего вечера!
Это все так, для общего кругозора, беру так сказать колличеством.
А качеством буду брать на курсе буры, там по реакту полный порядок.
Спасибо анончик, хорошего вечера!
>>5004
Ну пизда в общем, видимо придется продать душу дъяволу и уходить обратно в ВСК. Пиздец конечно, бесплатный опенсурс уделал платный редактор. Нормально там у них вообще всё в джетбрейнсах? Голова не болит? Срут нормально?
Ну пизда в общем, видимо придется продать душу дъяволу и уходить обратно в ВСК. Пиздец конечно, бесплатный опенсурс уделал платный редактор. Нормально там у них вообще всё в джетбрейнсах? Голова не болит? Срут нормально?
>>5050
Ох две тонны чая
Ох две тонны чая
>>4585
Какой вопрос - такая, знаешь ли, и реакция, создается ощущение, что ты вообще не понимаешь что такое dom. Браузер получает html, браузер у себя в памяти строит модель по этому html - DOM, и показывает ее тебе. Если ты вносишь изменения в DOM - они разумеется не сохраняются в полученный с сервера html, даже если он кеширован, и сбрасываются, как только ты закроешь или обновишь вкладку.
Какой вопрос - такая, знаешь ли, и реакция, создается ощущение, что ты вообще не понимаешь что такое dom. Браузер получает html, браузер у себя в памяти строит модель по этому html - DOM, и показывает ее тебе. Если ты вносишь изменения в DOM - они разумеется не сохраняются в полученный с сервера html, даже если он кеширован, и сбрасываются, как только ты закроешь или обновишь вкладку.
>>5057
Да я так и думал, вопрос не так сформулировал наверно.
Да я так и думал, вопрос не так сформулировал наверно.
>>4782
Как передавать? Через дрисню из классов и дата-атрибутов? Нет, спасибо.
Неудобная и всратая ебля с css-переменными.
Ну, это просто не так. Стайледы наоборот сокращают количество css-дрисни.
Схуяль 30 строчек? Сас-шиз, откуда ты себе это придумал?
Охуенно. "Не читал, но осуждаю". Типичный долбоёб, которому лишь бы спиздаануть своё охуенно важное мнение о том, в чём он даже не разбирается.
Нет, не то же самое. Я скидывал codesandbox и там видно что это не так.
Продолжай оправдываться.
>sass у тебя эту возможность не отнимает, хочешь - делай логику и передавай
Как передавать? Через дрисню из классов и дата-атрибутов? Нет, спасибо.
>Что тебе мешает сделать темизацию css-методами вместо ре-рендеринга всего приложения нахуй?
Неудобная и всратая ебля с css-переменными.
>Но больше кода пишут как раз sc-шизы
Ну, это просто не так. Стайледы наоборот сокращают количество css-дрисни.
>Охуительные истории, 30 строчек импортов - это заебись, они в начале файла и их не видно.
Схуяль 30 строчек? Сас-шиз, откуда ты себе это придумал?
>Что там в vue не ебу
Охуенно. "Не читал, но осуждаю". Типичный долбоёб, которому лишь бы спиздаануть своё охуенно важное мнение о том, в чём он даже не разбирается.
>хуярить sc внутри комопнента - это точно то же самое, что хуярить инлайн-стили вместо классов
Нет, не то же самое. Я скидывал codesandbox и там видно что это не так.
Продолжай оправдываться.
Есть для реакта генерилка компонентов, чтобы тс и шаблон в разных файлах?
И что в нем вместо ангуляровских модулей?
И что в нем вместо ангуляровских модулей?
>>5077
Через дрисню из пропсов, прямо как ты передаешь в sc
Действительно, очень сложно 10 переменных объявить и поменять по мере нужды, лучше ре-рендерить инлайн дрисню во всем приложении каждый раз.
Там видно только то, что лично ты ленивый дурачок и написал все в одном файле. Если ты так пишешь в реальное приложение, 200 строк компонента и 100 строк стилей в один файл, то это нахуй из профессии.
>Как передавать? Через дрисню из классов и дата-атрибутов?
Через дрисню из пропсов, прямо как ты передаешь в sc
>Неудобная и всратая ебля с css-переменными.
Действительно, очень сложно 10 переменных объявить и поменять по мере нужды, лучше ре-рендерить инлайн дрисню во всем приложении каждый раз.
>Я скидывал codesandbox и там видно что это не так.
Там видно только то, что лично ты ленивый дурачок и написал все в одном файле. Если ты так пишешь в реальное приложение, 200 строк компонента и 100 строк стилей в один файл, то это нахуй из профессии.
Как считаете, на сколько долгий перерыв в обучении можно сделать чтобы не проебать всё, что я узнал?
мимо 2 месяца дрочусь, нужно прерваться
мимо 2 месяца дрочусь, нужно прерваться
>>5083
Нет, там же не надо декораторы настраивать.
Просто в хук вынеси
https://codesandbox.io/s/elegant-nash-4ui2p?file=/src/cats/RandomKitty.tsx
Нет, там же не надо декораторы настраивать.
Просто в хук вынеси
https://codesandbox.io/s/elegant-nash-4ui2p?file=/src/cats/RandomKitty.tsx
75 Кб, 780x1040>>5099
За пару лет ничего не пропустишь, не переживай. Отдыхай.
За пару лет ничего не пропустишь, не переживай. Отдыхай.
>>5094
Не вижу в sc дрисни, это же не цсс-классы
Каждый раз? Один раз при смене темы, только делать это удобнее через ThemeProvider
Всё — это что? Одну кнопку? Я говорил, что компоненты вроде кнопок выносятся в отдельные файлы потому что они для общего пользования. Но именно здесь кнопка используется только в одном реакт компоненте поэтому она объявлена в нём же
Не совсем понимаю, почему я до сих пор не услышал ни одного преимущества саса, сас-шиз? Даже преимущество в 0.0000001 ms скорости обходится через linaria (компиляция стайледов в цсс). Какие твои оправдания, сас-шиз?
> Через дрисню из пропсов, прямо как ты передаешь в sc
Не вижу в sc дрисни, это же не цсс-классы
> Действительно, очень сложно 10 переменных объявить и поменять по мере нужды, лучше ре-рендерить инлайн дрисню во всем приложении каждый раз.
Каждый раз? Один раз при смене темы, только делать это удобнее через ThemeProvider
> Там видно только то, что лично ты ленивый дурачок и написал все в одном файле. Если ты так пишешь в реальное приложение, 200 строк компонента и 100 строк стилей в один файл, то это нахуй из профессии.
Всё — это что? Одну кнопку? Я говорил, что компоненты вроде кнопок выносятся в отдельные файлы потому что они для общего пользования. Но именно здесь кнопка используется только в одном реакт компоненте поэтому она объявлена в нём же
Не совсем понимаю, почему я до сих пор не услышал ни одного преимущества саса, сас-шиз? Даже преимущество в 0.0000001 ms скорости обходится через linaria (компиляция стайледов в цсс). Какие твои оправдания, сас-шиз?
>>5142
Шизло, я же тебе сказал, преимущества должен указывать ты, потому что именно ты пытаешься заменить стандартные ксс-классы на дрисню из магических темплейт строк с функциями и бексконечными ?. && чеками на любой пук, не предоставляя своему шизобесию никаких оправданий, кроме пердежа "итажи жапаскрипт, значит он удобнее". Пока преимуществ, кроме "можно серить там же, где и ешь" я не услышал. Пытайся лучше.
Шизло, я же тебе сказал, преимущества должен указывать ты, потому что именно ты пытаешься заменить стандартные ксс-классы на дрисню из магических темплейт строк с функциями и бексконечными ?. && чеками на любой пук, не предоставляя своему шизобесию никаких оправданий, кроме пердежа "итажи жапаскрипт, значит он удобнее". Пока преимуществ, кроме "можно серить там же, где и ешь" я не услышал. Пытайся лучше.
Аноны, подскажите, пожалуйста, где можно попрактиковаться в браузерном джаваскрипте? Не всякие задачки, которые можно и на других языках решить, а именно проработать всякие добавление/удаление узлов, фетчи, события, координаты окна/документа, формы итд
Вот типа такого:
https://htmlacademy.ru/projects/online-store/payment
Только бесплатно.
Вот типа такого:
https://htmlacademy.ru/projects/online-store/payment
Только бесплатно.
>>5155
Придумываешь веб-приложение. Делаешь.
Придумываешь веб-приложение. Делаешь.
>>5099
Ну я делал перерыв примерно на 1.5 месяца, после этого было ощущение, что забыл вообще всё, но за пару дней дроча вернулся на место
Ну я делал перерыв примерно на 1.5 месяца, после этого было ощущение, что забыл вообще всё, но за пару дней дроча вернулся на место
>>5153
>>5094
Шизы, хватит срать. Просто покажи мне условный медиазапрос в css, когда у тебя один и тот же элемент должен делать запрос по разной ширине, если к примеру слева какая-то менюшка открыта или закрыта. И таких медиазапросов у тебя может быть 4 штуки. В СК это делается парой строчек. В ЦСС ты будешь срать кровавым поносом
>>5094
Шизы, хватит срать. Просто покажи мне условный медиазапрос в css, когда у тебя один и тот же элемент должен делать запрос по разной ширине, если к примеру слева какая-то менюшка открыта или закрыта. И таких медиазапросов у тебя может быть 4 штуки. В СК это делается парой строчек. В ЦСС ты будешь срать кровавым поносом
>>5172
Ты ради всплывающих менюшек будешь весь лэйаут пидорасить? Но вообще-то относительные величины поддерживаются даже третьим эксплорером.
Теперь понятен психопрофиль потребителей стайлед элементс.
>если к примеру слева какая-то менюшка открыта или закрыта
Ты ради всплывающих менюшек будешь весь лэйаут пидорасить? Но вообще-то относительные величины поддерживаются даже третьим эксплорером.
Теперь понятен психопрофиль потребителей стайлед элементс.
125 Кб, 1024x1024>>5177
Психопрофиль стайлед-бояр: стремятся изучать новое, применяют современные, более функциональные инструменты в разработке. В отличие от сас-шизов не стремятся пилить бревно перочинным ножичком, а используют для этого бензопилу. Быстрее делают свою работу благодаря более рациональному подходу и владению эффективными инструментами. В них живёт дух молодости, исследования, открытости, прагматичности. Предпочитают находиться в авангарде технологий, их стек всегда востребован, им постоянно предлагают работу с всё более крупной компенсацией, их любят коллеги-зумеры и тяночки из HR-отдеда, а коллеги-бумеры их боятся и избегают зрительного контакта с ними. Их профиль на линкедине спамят рекрутеры из США, Австралии, Сингапура и Нидерландов, в то время как сас-шизы довольствуются редкими подачками предложений с пост-советских актсорс-параш.
Психопрофиль сас-шизов: ретрограды, имеют нездоровую привязанность к архаичным моделям, их психика утратила гибкость и подвижность. В общем, это закостенелые бумеры, боящиеся вылезти из зоны комфорта. Неолуддиты из мира разработки интерфейсов. Отсутствует понимание о том, что такое чистота в коде, эстетика им чужда. Любят защищать громоздкие конструкции, к которым они привыкли, ведь из-за ригидной психики новые изменения приносят им боль. Их существование наполнено страхом потерять работу из-за неактуально стека технологий, который они используют. Фронтенд разработка приносит особенно много боли сас-шизам, ведь здесь скорость изменения технологий наиболее высокая. Сас-шизов презирают сообществах наиболее сильных и высокооплачиваемых разработчиков. Им рады только на галерах, где они могут с радостью для себя дрочить легаси сас-дрисню за низкий прайс, после чего спустя несколько лет они будут вытеснены с рынка из-за выборочного эйджизма, который не применяется к светлым умам стайлед-бояр, в которых живёт дух молодости даже в солидном возрасте.
Психопрофиль стайлед-бояр: стремятся изучать новое, применяют современные, более функциональные инструменты в разработке. В отличие от сас-шизов не стремятся пилить бревно перочинным ножичком, а используют для этого бензопилу. Быстрее делают свою работу благодаря более рациональному подходу и владению эффективными инструментами. В них живёт дух молодости, исследования, открытости, прагматичности. Предпочитают находиться в авангарде технологий, их стек всегда востребован, им постоянно предлагают работу с всё более крупной компенсацией, их любят коллеги-зумеры и тяночки из HR-отдеда, а коллеги-бумеры их боятся и избегают зрительного контакта с ними. Их профиль на линкедине спамят рекрутеры из США, Австралии, Сингапура и Нидерландов, в то время как сас-шизы довольствуются редкими подачками предложений с пост-советских актсорс-параш.
Психопрофиль сас-шизов: ретрограды, имеют нездоровую привязанность к архаичным моделям, их психика утратила гибкость и подвижность. В общем, это закостенелые бумеры, боящиеся вылезти из зоны комфорта. Неолуддиты из мира разработки интерфейсов. Отсутствует понимание о том, что такое чистота в коде, эстетика им чужда. Любят защищать громоздкие конструкции, к которым они привыкли, ведь из-за ригидной психики новые изменения приносят им боль. Их существование наполнено страхом потерять работу из-за неактуально стека технологий, который они используют. Фронтенд разработка приносит особенно много боли сас-шизам, ведь здесь скорость изменения технологий наиболее высокая. Сас-шизов презирают сообществах наиболее сильных и высокооплачиваемых разработчиков. Им рады только на галерах, где они могут с радостью для себя дрочить легаси сас-дрисню за низкий прайс, после чего спустя несколько лет они будут вытеснены с рынка из-за выборочного эйджизма, который не применяется к светлым умам стайлед-бояр, в которых живёт дух молодости даже в солидном возрасте.
>>5179
Писание стилей в жс так же старо, как сам жиквери. Скорее переизобретают велосипед, причём с гексагональными колёсами и с нечётным количеством этих колёс. Зато новое!
>стремятся изучать новое
Писание стилей в жс так же старо, как сам жиквери. Скорее переизобретают велосипед, причём с гексагональными колёсами и с нечётным количеством этих колёс. Зато новое!
>>5171
А сейчас как успехи?
А сейчас как успехи?
>>5172
Любую сложную хуйню, вроде вычисления ширины динамически на основе ширины других элементов, делать нужно через жс и изолировать от всего остального, а не пытаться накостылять это через медиа-запросы и стандартные стили.
Любую сложную хуйню, вроде вычисления ширины динамически на основе ширины других элементов, делать нужно через жс и изолировать от всего остального, а не пытаться накостылять это через медиа-запросы и стандартные стили.
>>0886 (OP)
Я не понимаю, почему мой по клику не меняется значение в стейте. Я уже все что можно перепробывал
https://codesandbox.io/s/tender-christian-4igcw?fontsize=14&hidenavigation=1&theme=dark
Я не понимаю, почему мой по клику не меняется значение в стейте. Я уже все что можно перепробывал
https://codesandbox.io/s/tender-christian-4igcw?fontsize=14&hidenavigation=1&theme=dark
75 Кб, 780x1040>>5265
Чмоня, ты?
Чмоня, ты?
Может кто пояснить, как здесь попапы всплывают плавно когда у него просто меняется display none на display block https://celluline.ru/
Как реализовать плавную анимацию без jquery?
Как реализовать плавную анимацию без jquery?
>>5297
На скок я понял там дисплей меняется моментально, а filter blur на заднем фоне катится с задержкой через transition
На скок я понял там дисплей меняется моментально, а filter blur на заднем фоне катится с задержкой через transition
>>5231
ну первая просто посмотреть что у меня в стейт отправилось
вторая для клика чтобы number передавался в стейт
легче будет использовать хуки для этого, но мне интересно почему это не работает и что я сделал не так
ну первая просто посмотреть что у меня в стейт отправилось
вторая для клика чтобы number передавался в стейт
легче будет использовать хуки для этого, но мне интересно почему это не работает и что я сделал не так
>>4025
Ахахахах
Что это за ебанибала? Вы поехавшие? Наху вы выжимаете из бедного языка все соки как баба постирушка на реке
Чем вам дефолтные инструменты не нравятся?
Ахахахах
Что это за ебанибала? Вы поехавшие? Наху вы выжимаете из бедного языка все соки как баба постирушка на реке
Чем вам дефолтные инструменты не нравятся?
>>5333
Какие?
Какие?
Прошёл 1 лвл javascript.info. Почти нихуя не понял, больше половины не перескажу. Что делать и нормально ли это?
>>5422
Нахуй ты это проходил? Начни верстать страницу, похуй какую, жс это довесок вёрстки
Нахуй ты это проходил? Начни верстать страницу, похуй какую, жс это довесок вёрстки
>>5426
Один же хуй пригодится когда на фреймворки пойду. В вёрстку с жс умею.
Один же хуй пригодится когда на фреймворки пойду. В вёрстку с жс умею.
Может кто нибудь объяснить, почему когда мы передаем функцию в аргумент другой функции.
function sum(argument1, argument2){
argument1(){}};
argument2(){};
}
То что бы потом потом вызвать функцию с аргументом, мы должны написать не имя переданной:
let randomFunc = function(){console.log("1+1")}
sum(argument1, randomfunc)
функции ее обертку в анонимную функцию? вот так:
sum (argument1, function(){randomFunc()})
function sum(argument1, argument2){
argument1(){}};
argument2(){};
}
То что бы потом потом вызвать функцию с аргументом, мы должны написать не имя переданной:
let randomFunc = function(){console.log("1+1")}
sum(argument1, randomfunc)
функции ее обертку в анонимную функцию? вот так:
sum (argument1, function(){randomFunc()})
>>5433
т.е. почему мы оборачиваем в анонимную функцию, функцию которая передана аргументом?
т.е. почему мы оборачиваем в анонимную функцию, функцию которая передана аргументом?
>>5426
Залетная пхп чмоня, ты? Срыгни нахуй лендос пилить за мивину
Залетная пхп чмоня, ты? Срыгни нахуй лендос пилить за мивину
>>5462
А ты не вызывай ее сразу.
А ты не вызывай ее сразу.
>>5503
Даже с асс ненужное переговно.
Жиквери до сих пор применибельный если лень много писать ебанины для васяна за 5000 сайт. Ты небось и в лендос интерактивную кнопку без энпиэма не пойдешь добавлять.
Крякт это вообще отдельная история.
Даже с асс ненужное переговно.
Жиквери до сих пор применибельный если лень много писать ебанины для васяна за 5000 сайт. Ты небось и в лендос интерактивную кнопку без энпиэма не пойдешь добавлять.
Крякт это вообще отдельная история.
>>5433
function idi( na, hui ) {
console.log( "idi" + na() + hui() );
}
function v() { return "v"; }
function pizdu() { return "pizdu"; }
idi(v, pizdu);
function idi( na, hui ) {
console.log( "idi" + na() + hui() );
}
function v() { return "v"; }
function pizdu() { return "pizdu"; }
idi(v, pizdu);
Как вкатиться аноны, кажись создать телепортацию будет проще, чем изучить эти строки бессмысленного текста
>>5533
Через 5 месяцев на землю метеорит упадет? Реакт не настолько уж сложный, лучше как следует задрочи ЖС
Через 5 месяцев на землю метеорит упадет? Реакт не настолько уж сложный, лучше как следует задрочи ЖС
>>5568
Нет, я выпущусь из универа, съеду с общаги и сниму квартиру. Нужно будет идти на работу.
Нет, я выпущусь из универа, съеду с общаги и сниму квартиру. Нужно будет идти на работу.
mobx
>>5579
Проблемы нет, есть вопрос, как распределить время. По Реакту много вакансий, поэтому буду учить его. Хочу знать, сколько месяцев надо учить/практиковать JS перед Реактом.
Проблемы нет, есть вопрос, как распределить время. По Реакту много вакансий, поэтому буду учить его. Хочу знать, сколько месяцев надо учить/практиковать JS перед Реактом.
>>5562
Понял, return надо ставить. Спасибо анончик!
Понял, return надо ставить. Спасибо анончик!
>>5624
<form action="script.php">
<input name="danniiie">
<button type=submit>peredaet</button>
</form>
<?php echo $_POST['dannie']; ?>
<form action="script.php">
<input name="danniiie">
<button type=submit>peredaet</button>
</form>
<?php echo $_POST['dannie']; ?>
>>5624
Невозможно.
Невозможно.
>>5643
Если у тебя 30 кнопок, тебе 30 батонов всё равно придется делать. А инпутов это уж сколько тебе данных надо передать.
Если у тебя 30 кнопок, тебе 30 батонов всё равно придется делать. А инпутов это уж сколько тебе данных надо передать.
>>5646
я думал,что можно допустим нажать 10 кнопок(они должны подсветится красным),а рядом в форме шло перечисление того,что я нажал и потом одной кнопкой это все отправить пхп и в БД(советуют жсон формат исп)чтобы не херачить кучу колонок в БД
я думал,что можно допустим нажать 10 кнопок(они должны подсветится красным),а рядом в форме шло перечисление того,что я нажал и потом одной кнопкой это все отправить пхп и в БД(советуют жсон формат исп)чтобы не херачить кучу колонок в БД
>>5648
Предупредить о том, что тебе некомфортно?
Предупредить о том, что тебе некомфортно?
>>5655
чекбоксы ни как нельзя там использовать,стиль должен быть именно как кнопка( или активное поле)
чекбоксы ни как нельзя там использовать,стиль должен быть именно как кнопка( или активное поле)
Сап, фронты, скажите как вебсервис должен отдавать файлы на фронт, пишу апи и понадобилось отдавать mp3, быстро глянул что там есть какие-то обертки для этого, возник вопрос как именно на фронте рендеряться медиа файлы, мне, например нужно сделать так как я понимаю, у пользователя есть список mp3, его фронт получает с запроса на аудио, списоком, потом они загружаются с сервера, потом пользователь может из слушать, верно? Так вот вопрос, написать api по которому можно просто скачать один файл это рабочий вариант? Как в таком случае обычно еще json отдаеться с названием, описанием и датой создания? Отедльный запрос делать на инфу по первичному ключу аудио? Помогите разобраться
>>5842
Или может достаточно майм тип сделать что это мп3 и тогда все будет ок?
Или может достаточно майм тип сделать что это мп3 и тогда все будет ок?
>>5863
при запросе вроде должен быть правильный майм тип, а он в хедерах отдается, хотя энивей хз важно ли это для фронта, ладно браузер понимает что делать, типа если майм тип мп3, то открыть, хтмл парсить и т.д, а как фронт это использует вообще не знаю
при запросе вроде должен быть правильный майм тип, а он в хедерах отдается, хотя энивей хз важно ли это для фронта, ладно браузер понимает что делать, типа если майм тип мп3, то открыть, хтмл парсить и т.д, а как фронт это использует вообще не знаю
Сюда же вопрос, вот я сделал 2-мя способами отдачу файла - 1. Возвращает по урлу мп3 и он открывается в браузере и 2. По урлу файл скачивается, я даже не знаю как у гугля правильно спросить в чем разница, а главное как фронт с этим работать будет
>>5897
Хуй знает что вы там делаете, но тебе похоже нечем заняться, так что сделай пока это
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range
Хуй знает что вы там делаете, но тебе похоже нечем заняться, так что сделай пока это
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range
19 Кб, 766x369>>5893
Аудио и видео на клиентской стороне в большинстве случаев обрабатывается через `<audio>` и `<video>` тэги, которые по сути контейнеры для ссылок, как `<img>`. Хуй знает, что ты там собираешься писать, в том же экспрессе по дефолту настраивается папка `public`, которая и отдаёт файлы без всяких дополнительных движений.
Если же надо оформлять ссылку на скачку, то достаточно указать `download` у ссылки.
Если же прям надо кишочки работы апи того же `<audio>`, то тут только читать https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API или спеку.
Аудио и видео на клиентской стороне в большинстве случаев обрабатывается через `<audio>` и `<video>` тэги, которые по сути контейнеры для ссылок, как `<img>`. Хуй знает, что ты там собираешься писать, в том же экспрессе по дефолту настраивается папка `public`, которая и отдаёт файлы без всяких дополнительных движений.
Если же надо оформлять ссылку на скачку, то достаточно указать `download` у ссылки.
Если же прям надо кишочки работы апи того же `<audio>`, то тут только читать https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API или спеку.
>>5918
А как-нибудь протестить эти теги можно? Паблик нельзя юзать, аудио считай голосовые сообщения и просто с медиа урла нельзя отдавать, нужна проверка прав, но при проверке получилось пока только именно скачивать, в обоих запросах и когда скачивается файл и когда именно в браузере появляется(как у картинок типа открыть оригинал, чисто картинка по урлу), в обоих запросах метод гет, майм тип один и тот же
А как-нибудь протестить эти теги можно? Паблик нельзя юзать, аудио считай голосовые сообщения и просто с медиа урла нельзя отдавать, нужна проверка прав, но при проверке получилось пока только именно скачивать, в обоих запросах и когда скачивается файл и когда именно в браузере появляется(как у картинок типа открыть оригинал, чисто картинка по урлу), в обоих запросах метод гет, майм тип один и тот же
>>5918
Я вдруг понял что есть ссылки с названием расширения .jpg, может от этого зависит?
Я вдруг понял что есть ссылки с названием расширения .jpg, может от этого зависит?
>>5932
Делаешь эти теги в шаблоне и можешь обтестироваться на тестовом сервере.
Просмотри https://developer.mozilla.org/en-US/docs/Web/HTML/Element/audio#attributes и если никак проверку прав через аттрибуты не сделать, то придётся нырять в интерфейс HTMLAudioElement и там уже пердолить свою реализацию запроса прав.
>А как-нибудь протестить эти теги можно?
Делаешь эти теги в шаблоне и можешь обтестироваться на тестовом сервере.
>Паблик нельзя юзать, аудио считай голосовые сообщения и просто с медиа урла нельзя отдавать, нужна проверка прав, но при проверке получилось пока только именно скачивать
Просмотри https://developer.mozilla.org/en-US/docs/Web/HTML/Element/audio#attributes и если никак проверку прав через аттрибуты не сделать, то придётся нырять в интерфейс HTMLAudioElement и там уже пердолить свою реализацию запроса прав.
>>5554
Нахуя, если есть чистый жс. И исходя из этого, нахуя нужен жиквери, если все на чистом жс делается?
>Ты небось и в лендос интерактивную кнопку без энпиэма не пойдешь добавлять
Нахуя, если есть чистый жс. И исходя из этого, нахуя нужен жиквери, если все на чистом жс делается?
>>5932
Да почти все медиасервисы так делают со статикой, урлы только хэшируют анально да от роботов прячут.
Можешь при загрузке статики токен какой-нибудь в заголовке или запросе проверять для авторизации. Можешь файлы в статику складывать только после запроса за метаданными и потом удалять. Можешь DRM обмазаться если совсем упорот.
Да почти все медиасервисы так делают со статикой, урлы только хэшируют анально да от роботов прячут.
Можешь при загрузке статики токен какой-нибудь в заголовке или запросе проверять для авторизации. Можешь файлы в статику складывать только после запроса за метаданными и потом удалять. Можешь DRM обмазаться если совсем упорот.
25 Кб, 400x400Аноны, я тут взялся пилить проект, который когда мне озвучивали я честно сказал что никогда сам от начала до конца не делал, но близкий опыт имею.
Суть моей части проекта в том чтобы написать полностью фронтенд, начиная от UI элементов с версткой до всей бизнес-логики работы с API. Проект сам это интернет-магазин PWA. Сделать надо на генераторе статических страниц Gatsby для оптимизона, при этом на него мне пришлось написать source-plugin для работы с их кастомным API. Сам Гатсби на реакте если что.
Ну так вот, я дал свой эстимейт закачику ио времени и цене, и уже поздно метаться, ибо по руками ударили, но я чет теперь думаю что я по неопытности взял слишком мало времени и денег и меня ждут бессонные ночи в попытках не проебать очередной дедлайн.
Дайте пожалуйста ваши примерные эстимейты на проект по времени и цене. ТЗ нет, потому что мне буквально точно также всё на словах раскидали, да знаю что пиздец, но кушать хочется.
Суть моей части проекта в том чтобы написать полностью фронтенд, начиная от UI элементов с версткой до всей бизнес-логики работы с API. Проект сам это интернет-магазин PWA. Сделать надо на генераторе статических страниц Gatsby для оптимизона, при этом на него мне пришлось написать source-plugin для работы с их кастомным API. Сам Гатсби на реакте если что.
Ну так вот, я дал свой эстимейт закачику ио времени и цене, и уже поздно метаться, ибо по руками ударили, но я чет теперь думаю что я по неопытности взял слишком мало времени и денег и меня ждут бессонные ночи в попытках не проебать очередной дедлайн.
Дайте пожалуйста ваши примерные эстимейты на проект по времени и цене. ТЗ нет, потому что мне буквально точно также всё на словах раскидали, да знаю что пиздец, но кушать хочется.
>>5724
Внезапно css.
Внезапно css.
>>5976
<button onclick="myFunction()">Click me</button>
function myFunction() {
document.getElementById("demo").innerHTML = "Hello World";
}
Куда быстрее?
<button onclick="myFunction()">Click me</button>
function myFunction() {
document.getElementById("demo").innerHTML = "Hello World";
}
Куда быстрее?
106 Кб, 935x528>>5979
Хорош!
Хорош!
>>5979
Показательный код человека, который не знает ванильного жс и вебапи, но думает, что знает заебись.
Показательный код человека, который не знает ванильного жс и вебапи, но думает, что знает заебись.
>>5967
На апворке посмотри
На апворке посмотри
305 Кб, 960x960Поясните, как этот ваш евент луп работает? Сколько не смотрю, не читаю - нихуя не пойму.
Возьмем к примеру нодовский модуль http представим, что я делаю 10 асинхронных запросов на удаленный сервер. Задачи ставятся в очередь, но не блокируют друг друга, т.е. возвращается ответ на запрос, который пришел первым, а не был первым поставлен в список задач.
Это что получается? Эти задачи выполняются параллельно? Т.е. не в одном потоке? Но нода однопоточна же. Гдето краем уха услышал, что многопоточность реализует не язык, а окружение, в котором язык выполняется, например в браузере - браузер, у ноды с++ (или что там).
Поясните про эту хуйню короч.
Возьмем к примеру нодовский модуль http представим, что я делаю 10 асинхронных запросов на удаленный сервер. Задачи ставятся в очередь, но не блокируют друг друга, т.е. возвращается ответ на запрос, который пришел первым, а не был первым поставлен в список задач.
Это что получается? Эти задачи выполняются параллельно? Т.е. не в одном потоке? Но нода однопоточна же. Гдето краем уха услышал, что многопоточность реализует не язык, а окружение, в котором язык выполняется, например в браузере - браузер, у ноды с++ (или что там).
Поясните про эту хуйню короч.
>>6191
Все верно, движок не выполняет ио, а ждёт ответов от ио устройств
Все верно, движок не выполняет ио, а ждёт ответов от ио устройств
>>6212
Этим занимается движок браузера или ноды. И он не возвращает ответ. Он переводит промис в состояние фуллфиллд и запихивает ф-ю, которую ты вписал в then в конец очереди микрозадач.
Этим занимается движок браузера или ноды. И он не возвращает ответ. Он переводит промис в состояние фуллфиллд и запихивает ф-ю, которую ты вписал в then в конец очереди микрозадач.
>>6191
Однопоточна в том смысле, что у тебя один event loop и одновременно может выполняться только одна строчка JS кода. Но fetch и setTimeout это не JS-код и они там могут быть хоть 100-поточными. Когда ты пишешь fetch то тебе в ЖС сразу (!) возвращается промис, на этом JS переходит к следующей строчке, а самим XHR занимается уже браузер и как -- это его дело. С таймером то же самое, ВСЕ джуны валятся на этой хуйне. setTimeout возвращает идентификатор таймера МГНОВЕННО и сразу после этого JS выполняется дальше, таймер тикает в браузере и когда таймер заканчивается, то браузер просто ставит переданный в setTimeout callback в очередь макрозадач. Ни таймеры ни XHR не являются фичей джаваскрипта, это фичи БРАУЗЕРА (ну или ноды или любого другого окружения).
>Но нода однопоточна же.
Однопоточна в том смысле, что у тебя один event loop и одновременно может выполняться только одна строчка JS кода. Но fetch и setTimeout это не JS-код и они там могут быть хоть 100-поточными. Когда ты пишешь fetch то тебе в ЖС сразу (!) возвращается промис, на этом JS переходит к следующей строчке, а самим XHR занимается уже браузер и как -- это его дело. С таймером то же самое, ВСЕ джуны валятся на этой хуйне. setTimeout возвращает идентификатор таймера МГНОВЕННО и сразу после этого JS выполняется дальше, таймер тикает в браузере и когда таймер заканчивается, то браузер просто ставит переданный в setTimeout callback в очередь макрозадач. Ни таймеры ни XHR не являются фичей джаваскрипта, это фичи БРАУЗЕРА (ну или ноды или любого другого окружения).
>>6253
Хорошо, как движок браузера понимает, когда значение зарезволилось и его можно перенести в состояние фулфиллд и отдать? Опрашивает промис раз в n миллисекунд?
Хорошо, как движок браузера понимает, когда значение зарезволилось и его можно перенести в состояние фулфиллд и отдать? Опрашивает промис раз в n миллисекунд?
>>6273
В смысле опрашивает промис, чо ты несёшь? Движок браузера написан на С++ и он в случае с фетчем делает днс запрос, открывает соединение на нужный айпишник и шлёт туда байтики, потом получает обратно из сокета какие-то байтики, смотрит хорошие это байтики или не очень и в зависимости от этого переводит промис на стороне ЖС в одно из состояний фуллфиллд или реджектед. Ну или может быть он вообще достаёт файл из кэша, может из дискового, может из оперативки.
Што? Промис это просто объект в JS - его не опрашивают. Он создаётся и при создании получает значение пендинг. Потом он обязан быть переведён в фуллфиллед или реджектед, после чего в очередь микрозадач движком ставится соответствующая таска.
В смысле опрашивает промис, чо ты несёшь? Движок браузера написан на С++ и он в случае с фетчем делает днс запрос, открывает соединение на нужный айпишник и шлёт туда байтики, потом получает обратно из сокета какие-то байтики, смотрит хорошие это байтики или не очень и в зависимости от этого переводит промис на стороне ЖС в одно из состояний фуллфиллд или реджектед. Ну или может быть он вообще достаёт файл из кэша, может из дискового, может из оперативки.
>Опрашивает промис раз в n миллисекунд?
Што? Промис это просто объект в JS - его не опрашивают. Он создаётся и при создании получает значение пендинг. Потом он обязан быть переведён в фуллфиллед или реджектед, после чего в очередь микрозадач движком ставится соответствующая таска.
>>6253
А можно подробней узнать про эту очередь микрозадач? Чисто для общего развития интересно как это устроено.
А можно подробней узнать про эту очередь микрозадач? Чисто для общего развития интересно как это устроено.
>>6259
Можно сказать, что все асинхронные операции - это не ЖС? Т.е. жс просто имеет синтаксис для вызова этих операций в отдельном потоке и обработки результата, но сама работа делается устройством?
Можно сказать, что все асинхронные операции - это не ЖС? Т.е. жс просто имеет синтаксис для вызова этих операций в отдельном потоке и обработки результата, но сама работа делается устройством?
>>6296
Ебать, теперь это называется для общего развития кек?
https://www.youtube.com/watch?v=cCOL7MC4Pl0
https://learn.javascript.ru/event-loop
Ебать, теперь это называется для общего развития кек?
https://www.youtube.com/watch?v=cCOL7MC4Pl0
https://learn.javascript.ru/event-loop
>>6289
В контексте Chrome -- да. Движок firefox например на джаве написан.
Так уже понятней.
Вот это https://chromium.googlesource.com/v8/v8/+/3.29.45/src/promise.js?autodive=0/ вроде как реализация промиса в V8.
>Движок браузера написан на C++
В контексте Chrome -- да. Движок firefox например на джаве написан.
>в случае с фетчем делает днс запрос, открывает соединение на нужный айпишник и шлёт туда байтики, потом получает обратно из сокета какие-то байтики, смотрит хорошие это байтики или не очень и в зависимости от этого переводит промис на стороне ЖС в одно из состояний фуллфиллд или реджектед.
Так уже понятней.
Вот это https://chromium.googlesource.com/v8/v8/+/3.29.45/src/promise.js?autodive=0/ вроде как реализация промиса в V8.
>>6298
На практике да, это выглядит именно так.
>>6298
Да
Обработку в том смысле, что он ставит задачу в одну из очередей, да. С самим результатом ты уже всё разбираешься сам в коде коллбэков своих.
Ответ на этот вопрос не относится к ECMAScript. Он знает, что промис рано или поздно будет фуллфилд или реджектед, на этом всё и это гарантируется. Будет там браузер поднимать для этого потоки, устанавливать соединения или пойдёт в кэш дисковый или в кэш памяти - ECMAScript'у категорически похуй.
>все асинхронные операции - это не ЖС
На практике да, это выглядит именно так.
>>6298
>имеет синтаксис для вызова этих операций
Да
>и обработки результата
Обработку в том смысле, что он ставит задачу в одну из очередей, да. С самим результатом ты уже всё разбираешься сам в коде коллбэков своих.
>сама работа делается устройством
Ответ на этот вопрос не относится к ECMAScript. Он знает, что промис рано или поздно будет фуллфилд или реджектед, на этом всё и это гарантируется. Будет там браузер поднимать для этого потоки, устанавливать соединения или пойдёт в кэш дисковый или в кэш памяти - ECMAScript'у категорически похуй.
>>6307
Добра. На все ответил
Добра. На все ответил
>>6306
Знание того, как оно устроено внутри в движке абсолютно бесполезно. По крайней мере на том уровне, пока ты не понимаешь досконально то, как это выглядит снаружи, что гарантируется, в каком порядке итд итп. А как только ты с этим разберёшься, то у тебя про внутренние детали браузера вопросы сразу и исчезнут, потому что это не имеет значения. Сам там был. Когда разберёшься с event loop, у тебя пропадёт неуверенность и непонимание того, чо в каком порядке происходит в твоем коде и почему оно так делает, и браузер тогда из твоего поля внимания исчезнет. Сейчас ты чтением исходников хрома пытаешься прикрыть пробелы в понимании, не трать время.
Купи лол скачай конечно же сам знаешь откуда https://frontendmasters.com/courses/javascript-hard-parts-v2/ и пересмотри хотя бы раза 2-3, оно стоит того.
Знание того, как оно устроено внутри в движке абсолютно бесполезно. По крайней мере на том уровне, пока ты не понимаешь досконально то, как это выглядит снаружи, что гарантируется, в каком порядке итд итп. А как только ты с этим разберёшься, то у тебя про внутренние детали браузера вопросы сразу и исчезнут, потому что это не имеет значения. Сам там был. Когда разберёшься с event loop, у тебя пропадёт неуверенность и непонимание того, чо в каком порядке происходит в твоем коде и почему оно так делает, и браузер тогда из твоего поля внимания исчезнет. Сейчас ты чтением исходников хрома пытаешься прикрыть пробелы в понимании, не трать время.
Купи лол скачай конечно же сам знаешь откуда https://frontendmasters.com/courses/javascript-hard-parts-v2/ и пересмотри хотя бы раза 2-3, оно стоит того.
>>6316
Не делай поспешных выводов, дружище, про ивент-луп я читал уже и он не давал мне ответа на вопрос, который я спрашивал выше.
Не делай поспешных выводов, дружище, про ивент-луп я читал уже и он не давал мне ответа на вопрос, который я спрашивал выше.
>>6319
А то, в каком порядке выполняется код я и так знаю, вот тут ивент луп помог разобраться.
А то, в каком порядке выполняется код я и так знаю, вот тут ивент луп помог разобраться.
>>6319
В последней ссылке есть буквально ответ на вопрос, который ты спрашивал выше. Вот прям буквально про fetch, поэтому я тебе эту ссылку и кинул.
И да, тот чел рассказывает ОЧЕНЬ душно и подробно, но я не советую на первой итерации скипать. На второй-третьей уже можно, ессно.
Алсо, далеко не все курсы с того сайта я бы рекомендовал. бОльшая часть там всё же неплохие, но есть и не очень удачные и просто запредельное говно.
В последней ссылке есть буквально ответ на вопрос, который ты спрашивал выше. Вот прям буквально про fetch, поэтому я тебе эту ссылку и кинул.
И да, тот чел рассказывает ОЧЕНЬ душно и подробно, но я не советую на первой итерации скипать. На второй-третьей уже можно, ессно.
Алсо, далеко не все курсы с того сайта я бы рекомендовал. бОльшая часть там всё же неплохие, но есть и не очень удачные и просто запредельное говно.
>>0886 (OP)
В жс всё является объектом как пистоне или есть какие-то исключения?
В жс всё является объектом как пистоне или есть какие-то исключения?
>>6298
Не устройством, а окружением.
JS это встраиваемый язык без средств ввода/вывода.
Он нужен для программирования среды, в которую он встроен. А встроен он может быть куда угодно - браузер, нода, фотошоп, автокад, ардуино, и сотни других даже есть ядра операционной системы, где js engine работает в нулевом кольце и на нем ты можешь программировать, например, планировщик потоков этой операционки или аллокатор памяти.
Вот есть язык Lua, который исторически встраивают в игровые движки, чтобы писать игровую логику. Есть тысячи других встраиваемых языков программирования. ЖС ровно для того же нужен. Только он многим мощнее и выразительнее всех прочих встраиваемых, и с ортодоксальным синтаксисом.
>сама работа делается устройством?
Не устройством, а окружением.
JS это встраиваемый язык без средств ввода/вывода.
Он нужен для программирования среды, в которую он встроен. А встроен он может быть куда угодно - браузер, нода, фотошоп, автокад, ардуино, и сотни других даже есть ядра операционной системы, где js engine работает в нулевом кольце и на нем ты можешь программировать, например, планировщик потоков этой операционки или аллокатор памяти.
Вот есть язык Lua, который исторически встраивают в игровые движки, чтобы писать игровую логику. Есть тысячи других встраиваемых языков программирования. ЖС ровно для того же нужен. Только он многим мощнее и выразительнее всех прочих встраиваемых, и с ортодоксальным синтаксисом.
Как побороть NPM зависимость? Вот делаю небольшой сайт, в принципе количество нпм пакетов в нем вообще ни на что не влияет. Но суть в том, что интересно было бы и самому реализовать какой-то функционал предоставляемый нпм пакетом, но если я буду пилить его руками, то уйдет очень много времени, а тут поставил и всё. Как вы пришли к тому, что все начали пилить руками? Как вообще понять, что что-то стоит затраченного времени? Хочется с одной стороны поднимать скилл, с другой не хочется тратить очень много времени на то, что кто-то до тебя уже сделал, и вроде бы тратить время заказчика на своё обучение тоже не очень-то прилично вроде как
>>6422
Зачем? Руками имеет смысл пилить какие-то учебные вещи, чтобы разобраться с концепцией. А библиотеки - это глупо. Там очень много рутинной работы, которая к повышению скиллов отношения не имеет.
Запили реализацию async/await через генераторы, например. Хорошее упражнение. Займёт у тебя от 3 минут до 1 месяца и повысит твой скилл.
>Как вы пришли к тому, что все начали пилить руками?
Зачем? Руками имеет смысл пилить какие-то учебные вещи, чтобы разобраться с концепцией. А библиотеки - это глупо. Там очень много рутинной работы, которая к повышению скиллов отношения не имеет.
Запили реализацию async/await через генераторы, например. Хорошее упражнение. Займёт у тебя от 3 минут до 1 месяца и повысит твой скилл.
>>6397
Да. А ты?
Да. А ты?
>>6431
Но ведь async/await это обертка над промисами... Это в питоне том же асинхронность на генераторах
>async/await через генераторы
Но ведь async/await это обертка над промисами... Это в питоне том же асинхронность на генераторах
>>6495
Обертка, но реализация то
Обертка, но реализация то
34 Кб, 735x377Всем советую пикролл. Кантор моча ебаная, после него мдн шерстил как сука. С этими видосами понял все моменты на которых затыки были.
>>6536
10 лет назад.
10 лет назад.
Вернёмся к event loop, requestAnimationFrame в какую очередь попадает и кто его тригеррит?
>>6644
С микротасков
С микротасков
154 Кб, 1200x1023Читаю Кантора. До главы "Продвинутые функции" было всё понятно на 100%. Дальше понимание снизилось до 80-90%. Когда дошел до прототипов и наследований понимание снизилось до 60-70%. На промисах понимание упало до 50%. Главу с генераторами вообще два дня читал и перечитывал, плюс на других сайтах гуглил материалы на эту тему, чтобы понять каким образом работает передача значения в генератор. Потом вроде бы понял, а на следующий день осознал, что потерял понимание. Забил хуй, стал читать дальше - работа с ошибками, главу "Разное", манипуляции с DOM - там вроде как понятно, но память стала вообще дырявая, синтаксис вообще перестал запоминаться. Чё делать? Смогу ли я вкатиться, если даже базовые вещи не особо понимаю? Ещё верстаю как дебил, не по БЭМу. Не умею в анимации, раскрывающиеся менюшки, попапы и т.д. - копирую готовые. Адаптивность делаю через жопу: верстаю сперва ПК-версию, потом начинаю понемногу уменьшать разрешение экрана (инструмент "Адаптивный дизайн" в Firefox), и когда какой-нибудь элемент перестаёт вписываться, то я останавливаюсь и через media-запрос прописываю для него новые свойства. Мне кажется, что по-умному это делается как-то иначе
1,4 Мб, 1000x637>>6667
Ты дэбил?
Ты дэбил?
>>6689
Или вкатиться, или умереть. На завод не смогу.
>Вот в такие моменты решается сможешь ты вкатиться или нет. Либо бери себя в руки и долбись дальше, либо бросай это дело и пиздуй на завод.
Или вкатиться, или умереть. На завод не смогу.
>>6671
Правильно кажется. Есть определённый набор разрешений под которые стараются адаптировать. Чем больше набор тем больше бабла берут. Алсо, по моему опыту mobile-first делать легче.
>Мне кажется, что по-умному это делается как-то иначе
Правильно кажется. Есть определённый набор разрешений под которые стараются адаптировать. Чем больше набор тем больше бабла берут. Алсо, по моему опыту mobile-first делать легче.
Что за хуйня со Slick-слайдером на мобилках? Объясните раку. В адаптиве на ПК слайдер работает, когда переношу папку с файлами на телефон, слайдер отлетает. Сами стили телефон видит (решил через Total Commander), но слайдер тупо слетает. Responsive прописывал - не робит. В чем трабла? В том, что слайдер не робит таким образом, если я переношу папку непосредственно на смартфон?
>>6711
В девтулзах посмотри как у тебя стили не загрузились
В девтулзах посмотри как у тебя стили не загрузились
>>0886 (OP)
Нужно ли подчищать что-то вил анмаунтом после того как зафетчил что-то? Например как у меня сейчас, я фетчу с апи мои обьекты, массив полученный записываю в стейт, по вил апдейту этот стейт перезаписывается (с переходом на новую страничку)
Заметил что иногда страницы подружаются по 6 секунд (там 8 картинок 200х200 и чуть текста), иногда как-то подлагивает мб из-за того что где-то не анмаунтнул?
Нужно ли подчищать что-то вил анмаунтом после того как зафетчил что-то? Например как у меня сейчас, я фетчу с апи мои обьекты, массив полученный записываю в стейт, по вил апдейту этот стейт перезаписывается (с переходом на новую страничку)
Заметил что иногда страницы подружаются по 6 секунд (там 8 картинок 200х200 и чуть текста), иногда как-то подлагивает мб из-за того что где-то не анмаунтнул?
>>6732
Вопрос по реакту если что, чтоб никто не недоумевал
Вопрос по реакту если что, чтоб никто не недоумевал
>>6671
Так наоборот, дебилом бы был, если бы верстал по полностью устаревшей и ненужной отрыжке яндекса из 2010 года, вместо того, чтобы пользоваться сассом.
>Ещё верстаю как дебил, не по БЭМу
Так наоборот, дебилом бы был, если бы верстал по полностью устаревшей и ненужной отрыжке яндекса из 2010 года, вместо того, чтобы пользоваться сассом.
>>6732
Ну ты в девтулз посмотри сколько запрос выполняется. У тебя в теории могут быть утечки только когда руками вешаешь события.
>иногда страницы подружаются по 6 секунд
Ну ты в девтулз посмотри сколько запрос выполняется. У тебя в теории могут быть утечки только когда руками вешаешь события.
>>6734
Как связаны сасс и БЭМ? Вернее что тебе мешает верстать по БЭМ на сассе?
Как связаны сасс и БЭМ? Вернее что тебе мешает верстать по БЭМ на сассе?
Сап, двач. В чем проблема: есть iframe, я пытаюсь обратиться к его полю. Захожу в исходный код, смотрю нужный мне name, пишу в консоли documebt.getElementByName - все ок, нужное мне поле находится. Стоит мне обновить страницу, как все ломается и это поле больше не находится, пока я снова не зайду в исходный код и не найду его. Вар Ант того, что я меняю его кликом, пока ищу его в исходном коде исключен. Понимаю, что мало вводных, скажите, если что то ещё нужно. Жс я знаю на уровне гугления и пишу маленькое расширение для хрома для себя
>>6732
Анмаунт нужен в основном чтобы отписываться от каких-либо событий, хз что ты там хочешь подчищать, учитывая, что стейт и так очищается после удаления компонента. Хз что у тебя с картинками, но по хорошему ты их ниоткуда скачивать не должен, должен быть хостинг изображений и ты просто вставляешь ссылку оттуда в <img />, тогда это никак работу сайта стопать не будет.
Анмаунт нужен в основном чтобы отписываться от каких-либо событий, хз что ты там хочешь подчищать, учитывая, что стейт и так очищается после удаления компонента. Хз что у тебя с картинками, но по хорошему ты их ниоткуда скачивать не должен, должен быть хостинг изображений и ты просто вставляешь ссылку оттуда в <img />, тогда это никак работу сайта стопать не будет.
>>6770
То есть не получится у меня это сделать средствами жс?
То есть не получится у меня это сделать средствами жс?
>>6768
Твой код не дожидается момента, когда фрейм загрузит контент.
Вы вообще заебали проебывать понятие ВРЕМЕНИ.
Твой код не дожидается момента, когда фрейм загрузит контент.
Вы вообще заебали проебывать понятие ВРЕМЕНИ.
Продолжаем изучать джава скрипт вместе с аноном.
Сегодня мы с помощью библиотеки JQuery и функции animate придаем нашей страничке немного мобильности и живого вида!
Так же мы научимся как делать всплывающий upbutton.
Сегодня мы с помощью библиотеки JQuery и функции animate придаем нашей страничке немного мобильности и живого вида!
Так же мы научимся как делать всплывающий upbutton.
>>6191
Нода на плюсах параллелит, это движок для ЖС
https://www.toptal.com/back-end/server-side-io-performance-node-php-java-go
>Это что получается? Эти задачи выполняются параллельно? Т.е. не в одном потоке? Но нода однопоточна же.
Нода на плюсах параллелит, это движок для ЖС
https://www.toptal.com/back-end/server-side-io-performance-node-php-java-go
>>6781
Божественный синтаксис. До сих пор не понимаю, почему не пытались жукуэри развивать, а родили реакт.
Божественный синтаксис. До сих пор не понимаю, почему не пытались жукуэри развивать, а родили реакт.
>>6495
Каким образом у тебя промис может "остановить" выполнение функции, расскажи мне, пожалуйста. await может. и yield может.
>Но ведь async/await это обертка над промисами...
Каким образом у тебя промис может "остановить" выполнение функции, расскажи мне, пожалуйста. await может. и yield может.
>>6638
В ещё одну отдельную очередь. Макротаски дёргаются из очереди строго по одной за итерацию лупа. Микротаски выполняются за одну итерацию все по очереди, причём, если ты будешь на лету добавлять микротаски (синхронно резолвить промисы, например), то ты застарвишь очередь (это будет выглядеть как while (true) по сути). А коллбэки rAF выполняются когда браузер решит, что он готов рендерить и они выполняются за одну итерацию все, если их несколько, но вновь добавленные уже уйдут на следующую итерацию.
В ещё одну отдельную очередь. Макротаски дёргаются из очереди строго по одной за итерацию лупа. Микротаски выполняются за одну итерацию все по очереди, причём, если ты будешь на лету добавлять микротаски (синхронно резолвить промисы, например), то ты застарвишь очередь (это будет выглядеть как while (true) по сути). А коллбэки rAF выполняются когда браузер решит, что он готов рендерить и они выполняются за одну итерацию все, если их несколько, но вновь добавленные уже уйдут на следующую итерацию.
>>6324
Сейчас прохожу Кантора, потом думаю смотреть Frontend Masters. Какие их курсы ты бы однозначно порекомендовал?
другой анон
Сейчас прохожу Кантора, потом думаю смотреть Frontend Masters. Какие их курсы ты бы однозначно порекомендовал?
другой анон
>>6599
Сколько времени потратил на прохождение?
Сколько времени потратил на прохождение?
Двач.hk не отвечает.
Вы видите копию треда, сохраненную 13 мая 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Вы видите копию треда, сохраненную 13 мая 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.