В моём примере функция в скобках вызывается до создания ключа и записывает в ключ готовое значение. А в вашем примере это метод, а не свойство, он каждый раз вычисляет что-то, а не содержит готовое значение.
Вот обычный принцип, который работал испокон веков (осовременен):
function FirstConstructor(){
const t = this;
let privateVar = 123;
t.publicMethod = val => privateVar + val; // никаких this для приватных полей
}
function SecondConstructor(){
const t = this;
let privateVar = 456; // приватные поля не пересекутся с родителем
delete t.publicMethod; // удаляем метод и его в объекте не будет нигде
t.anotherPublicMethod = ()=> privateVar; // никаких this для приватных полей
function privateMethod(){ return privateVar } // нет this для приватных полей
t.thirdPublicMethod = ()=> privateMethod() + 7; // нет this для прив. методов
}
let myInstance = new FirstConstructor();
SecondConstructor.call( myInstance );
В результате выходит экземпляр, у которого нет прототипов (кроме стандартного), всё на одном уровне, честные приватные поля, работающие без this.#, и удалённый метод. Есть конечно недостатки, и их не мало, но и преимущества есть.
У меня тоже такое не популярное мнение. Но не потому что классы плохие для всего, а потому что в JS имеют особенности. Например мне не нравится прототипное наследование, имеющее контекст только в виде самого объекта и вечного this, и не позволяющее собрать объект несколькими конструкторами и делать в него примеси или замены полей без всякой иерархии (оставляя объект плоским одноуровневым).
Полностью отказываться от этого подхода не стоит. У него по-прежнему остались применения. Например скоуп для сиюминутных локальных функций, работающих с общей локальной переменной. Или например вычисление значения для ключа при написании объекта литералом. Эти случаи конечно можно обходить иначе, но есть нюансы.
У меня часто просыпается желание сообщить об ошибке. Но после нескольких случаев подряд я перестал даже думать о сообщении, а просто думаю «эх жаль что ошибка»:
— Когда пытаюсь сообщить, то владельцы думают, что я злостно критикую или что я какой-то конкурент;
— Не понимают о чём я вообще говорю, как-будто их поделие к ним вообще не относится;
— Думают, что это не моё дело;
— Возмущаются типа «на своё посмотри лучше»;
и прочее и прочее…
И это происходит даже на стек-оверфлоу!
Думаю что не обязательно. Потому что может быть не обязательной. Типа по умолчанию всё any как сейчас. Хотя наверное вы правы, так как будет везде код с типами в интернете.
Товарищи, подскажите зачем в последнее время заголовки имеют вид «Всё о ...» или «Всё, что вам нужно знать о ...», ведь всё сказать или знать не возможно. Какой смысл слова «всё» в подобных заголовках? Например в этой статье сказано не всё, например не о всех возможных свойствах со значением auto, и не обо всех нюансах значения auto.
У элемента picture есть один существенный недостаток. Если например он не загрузил нужный формат или не смог его отобразить, то на этом он останавливается. Это противоречит здравой логике, ведь в списке форматов ещё могут быть более тяжёлые альтернативы, лучшие чем ничего. Поэтому если ваш бэк генерит автоматом набор тегов, а скрипт-конвертер не создал лучшие форматы, юзер может ничего не увидеть вообще.
Ещё все элементы, не только иконки, должны быть выдержаны в одном весе. У вас везде разная толщина линий. Это стразу заметно и вызывает ощущение хаотичности и несвязности деталей. Ещё я бы советовал больше соответствовать дизайну корпуса. Если в нём иконки кнопок плоские, то в программе они должны быть такими же, а не тоньше или меньше или тридэшней. И сетку сделайте более выверенно — сейчас везде разные отступы и оси. А между соседними плашками поменьше теней, полосок, каких-то утолщений, разделителей и прочего мусора — это лишний дребезг. Вместо точечных и прочих «типа хайтечных» фонов лучше делать сплошные — так вы возьмёте уверенностью дизайна, а не украшениями.
На нескольких изображениях увидел градиенты и слабые отличия серых тонов. Представьте, что я устал и глаза под конец дня мутные. Слабое отличие тонов напрягает — нужно приноровиться глазами. А градиенты и тени под плашками делают дизайн старым или излишне выпуклым, что выбивается из общего стиля, как-будто вы не определились. Ещё иконки должны иметь общую толщину или вес. И когда плашку какую-то активируете, то лучше изменять её фон, а не делать яркую рамку. Потому что рамка менее контрастна издалека и выглядит менее уверенно.
До того как мой проект переехал на выделенный сервер, я метался по всяким «вечным» и «безлимитным» хостингам. На обложке они все оказывались крутыми и привлекательными, но потом приходилось от них срочно бежать. Например были: неявные ограничения в якобы-безлимитных тарифах, например на количество файлов или на их типы, или совсем глупые ограничения на количество не доставленных email-ов, после которых отправка вообще блокировалась, или бэкапы на безлимитке, которые перестают работать после определенного лимита. Были и проблемы с офертами, их корректировка находу, или специально многозначный или скрытый смысл.
В данной статье конечно речь не о хостинге, однако это всё равно не выделенный сервер, где все ресурсы твои, поэтому схожесть есть. И в оферте тут какие-то странные слова про использование ресурсов, как у хостинга, как будто аккаунт не изолирован.
Если проектик небольшой, то лучше платить не сразу много «навечно», а по мере необходимости понемногу. Потому что со временем многое меняется в проекте, особенно в растущем. И любое «навечно» или «безлимитно» — это всегда гемор, отложенный по времени, как часовая бомба. А переезд потом бывает очень сложным и нервным.
Если вы мне не верите, то найдите для себя тут ответы на следующие вопросы:
1) Как слово «навечно» закреплено в оферте, и какие обязательства исполнителя сквозят во всех пунктах договора, если это «навечно» прервётся?
2) Как исполнитель защищён от банкротства или от «передумывания»? Какие компании обязаны будут взять эстафету и поддерживать ваш аккаунт после этого?
3) Как вы будете защищены от скрытых формулировок и неоднозначных ограничений в будущем? Достаточно ли подробная оферта? Есть ли в ней всеобъемлющие слова об объёмах и ограничениях?
4) Подробно ли описан форс-мажор, и как в этом случае обстоит дело с «навечно».
5) Сохраняется ли «навечно» при авариях в датацентре?
и так далее…
Не думайте, что перечисленное вас не коснётся. Потом будет жалко денег и будет гемор изниоткуда.
Ещё отмечу то, что безлимиты усыпляют бдительность и вы пропустите все важные моменты, потому что будете думать, что раз безлимит, значит всё хорошо. Сразу делайтесь мега-предвзятым, и докапывайтесь до всего, так хотя бы получите интуицию перед покупкой. Потратьте время сейчас, иначе потом обязательно будете тратить его намного больше в крайне нервной обстановке.
Тоже использую данный подход в вебшторме. Но там есть много нюансов: не все проверки корректно работают, не всегда выводятся верные типы и прочее. Использую именно такой подход вместо TS по причинам:
1) TS компилируется во что-то другое, это «чёрный ящик» в итоге. Многие убеждают, что это не проблема, но у меня проблемы с этим бывают.
2) TS работает только на классах с прототипным наследованием. Но в JS наследование может быть не прототипным, а например на основе функций-конструкторов, которые имеют много преимуществ: простые в реализации честные приватные переменные без # и приватные методы, исключается необходимость вечного this, нет путаницы в this во вложенных функциях (не стрелочных) потому что он единый для всего кода внутри конструктора (const t = this), возможность композиции объекта многими конструкторами сразу и прочее. Недостатки понятно тоже есть.
3) Много времени тратится на верное разруливание типов вместо реальной задачи. Иногда может уйти день чтобы начитаться документации по TS и наконец сварганить мега-решение лишь для верной работы типов.
4) Все d.ts, что я видел, имеют ошибки и неточности. Приходится либо ограничивать что-то, либо дописывать прямо в d.ts, чего быть по идее не должно. Почему-то писатели d.ts ограничиваются официальными документациями модулей, где описаны всегда не все случаи. Например в jQuery при выборке возвращается вовсе не HTMLElement, а Element. Потому что можно сделать выборку из SVGElement например.
И много прочего, что сильно мешает. Получился холиварный комент, пардон. Имхо лучше бы в JS была типизация как когда-то в ActionScript3 — простая и ненавязчивая.
В результате выходит экземпляр, у которого нет прототипов (кроме стандартного), всё на одном уровне, честные приватные поля, работающие без this.#, и удалённый метод. Есть конечно недостатки, и их не мало, но и преимущества есть.
— Когда пытаюсь сообщить, то владельцы думают, что я злостно критикую или что я какой-то конкурент;
— Не понимают о чём я вообще говорю, как-будто их поделие к ним вообще не относится;
— Думают, что это не моё дело;
— Возмущаются типа «на своё посмотри лучше»;
и прочее и прочее…
И это происходит даже на стек-оверфлоу!
В данной статье конечно речь не о хостинге, однако это всё равно не выделенный сервер, где все ресурсы твои, поэтому схожесть есть. И в оферте тут какие-то странные слова про использование ресурсов, как у хостинга, как будто аккаунт не изолирован.
Если проектик небольшой, то лучше платить не сразу много «навечно», а по мере необходимости понемногу. Потому что со временем многое меняется в проекте, особенно в растущем. И любое «навечно» или «безлимитно» — это всегда гемор, отложенный по времени, как часовая бомба. А переезд потом бывает очень сложным и нервным.
Если вы мне не верите, то найдите для себя тут ответы на следующие вопросы:
1) Как слово «навечно» закреплено в оферте, и какие обязательства исполнителя сквозят во всех пунктах договора, если это «навечно» прервётся?
2) Как исполнитель защищён от банкротства или от «передумывания»? Какие компании обязаны будут взять эстафету и поддерживать ваш аккаунт после этого?
3) Как вы будете защищены от скрытых формулировок и неоднозначных ограничений в будущем? Достаточно ли подробная оферта? Есть ли в ней всеобъемлющие слова об объёмах и ограничениях?
4) Подробно ли описан форс-мажор, и как в этом случае обстоит дело с «навечно».
5) Сохраняется ли «навечно» при авариях в датацентре?
и так далее…
Не думайте, что перечисленное вас не коснётся. Потом будет жалко денег и будет гемор изниоткуда.
Ещё отмечу то, что безлимиты усыпляют бдительность и вы пропустите все важные моменты, потому что будете думать, что раз безлимит, значит всё хорошо. Сразу делайтесь мега-предвзятым, и докапывайтесь до всего, так хотя бы получите интуицию перед покупкой. Потратьте время сейчас, иначе потом обязательно будете тратить его намного больше в крайне нервной обстановке.
1) TS компилируется во что-то другое, это «чёрный ящик» в итоге. Многие убеждают, что это не проблема, но у меня проблемы с этим бывают.
2) TS работает только на классах с прототипным наследованием. Но в JS наследование может быть не прототипным, а например на основе функций-конструкторов, которые имеют много преимуществ: простые в реализации честные приватные переменные без # и приватные методы, исключается необходимость вечного this, нет путаницы в this во вложенных функциях (не стрелочных) потому что он единый для всего кода внутри конструктора (const t = this), возможность композиции объекта многими конструкторами сразу и прочее. Недостатки понятно тоже есть.
3) Много времени тратится на верное разруливание типов вместо реальной задачи. Иногда может уйти день чтобы начитаться документации по TS и наконец сварганить мега-решение лишь для верной работы типов.
4) Все d.ts, что я видел, имеют ошибки и неточности. Приходится либо ограничивать что-то, либо дописывать прямо в d.ts, чего быть по идее не должно. Почему-то писатели d.ts ограничиваются официальными документациями модулей, где описаны всегда не все случаи. Например в jQuery при выборке возвращается вовсе не HTMLElement, а Element. Потому что можно сделать выборку из SVGElement например.
И много прочего, что сильно мешает. Получился холиварный комент, пардон. Имхо лучше бы в JS была типизация как когда-то в ActionScript3 — простая и ненавязчивая.