беседа про выбор костылей для обхода некоторых спорных моментов JS

А когда class field войдёт в стандарт, все равно останется костылем?

Так-то js полон ими, но все равно интересно

А когда class field войдёт в стандарт, все равно останется костылем?

Ну так классы же — ето костыли над прототипами! 😄

в js недоклассы

просто синтаксический сахар

Так-то js полон ими, но все равно интересно

врятли, как сказали, es это костыли

Простите за нубский вопрос, а зачем метод объявлять как свойство? Просто потому, что так можно?

Простите за нубский вопрос, а зачем метод объявлять как свойство? Просто потому, что так можно?

Чтобы не делать бинд. Преимущество вкратце написано на моём скрине

Костыль как костыль

Простите за нубский вопрос, а зачем метод объявлять как свойство? Просто потому, что так можно?

чтобы он был привязан контекстом, и не просто свойстов, а стрелочной функцией

ну в случае на скрине выше можно объявить стрелочную функцию, там тогда this позаимствуется

А когда class field войдёт в стандарт, все равно останется костылем?

для обсуждаемой темы - останется, но это сильно прибавит явности коду, что есть большой плюс в любом случае

ну в случае на скрине выше можно объявить стрелочную функцию, там тогда this позаимствуется

если метод в классе не использует this то лучше вынести код в функцию или объявить статическим методом

Ты же просто класс, имитация прототипа, разве может класс написать симфонию, сделать шедевр?!?

Ты же просто класс, имитация прототипа, разве может класс написать симфонию, сделать шедевр?!?

Абстрактным стать не можешь

если метод в классе не использует this то лучше вынести код в функцию или объявить статическим методом

статический метод сложно переопределять

Чтоб бинд не прописывать

статический метод сложно переопределять

наследование vs композиция

да

наследование такая себе вещь) rust доказывает, как и многие фп языки

Лучше просто функция, чем статический метод

ну если с умом применять то норм, а не 100500 классов наследовать

Лучше просто функция, чем статический метод

вот с этим согласен

ну если с умом применять то норм, а не 100500 классов наследовать

чаще всего лучше композиция, очень редкий кейс, когда необходимо именно наследование

Наследство

Работаю на sequelize, все бы ничего, но дока у них дерьмо

У bookshelf не лучше, скажу я вам

и опять возвращаемся к тому, что в ноде пока что плохо с хорошим ORM

У bookshelf не лучше, скажу я вам

Customer.collection().fetch().then(function(collection) { // ... }); ох блин

и опять возвращаемся к тому, что в ноде пока что плохо с хорошим ORM

Соглашусь. Знакомый хвалил Objection.js, но я не использовал, поэтому ничего сказать не могу и хотелось бы услышать мнение эксперта

На данный момент Sequelize объективно самый функциональный но дока у них не айс Хотя я разобрался довольно быстро.

жаль Es6 классы не умеет

Вот кстати по поводу функциональности меня бы вполне устроил knex с минимальной надстройкой, чем Objection по сути и является

knex такое г

Почему же?

он багованный и работает через раз Да и функционала нехватает очень часто ИМХО

ну очевидно же потому что он так сказал

)

ну очевидно же потому что он так сказал

нахрена ты это написал? Какую цель преследовал?

knex такое г

потому же что и ты написал вот это

а пояснений нет ниже?

он багованный и работает через раз Да и функционала нехватает очень часто ИМХО

Ну, на баги мне натыкаться не приходилось. Разве что миграции иногда лажают, но всякое бывает

какую orm предложите, bookshelf или sequelize?

а для написания легковесного graphql api?

Что здесь подразумевается под легковесным?

большого специфического функционала не надо. несколько таблиц. и чтоб все работало из коробки

Гайз, а Content-Security-Policy ошибки можно как-то catch'ить через клиентский js?

большого специфического функционала не надо. несколько таблиц. и чтоб все работало из коробки

возьми sequelize я для тбота так и сделал, вообще не жалею))

большого специфического функционала не надо. несколько таблиц. и чтоб все работало из коробки

Sequelize советую. Мой опыт показал, что sequelize не очень хорошо скейлится, но если несколько таблиц, то всё должно быть норм

Гайз, а Content-Security-Policy ошибки можно как-то catch'ить через клиентский js?

если есть доступ к бэку проще делать это через него по report-uri:

еще вот такое пишут https://www.w3.org/TR/CSP2/#securitypolicyviolationevent

если есть доступ к бэку проще делать это через него по report-uri:

Только клиентский код(

еще вот такое пишут https://www.w3.org/TR/CSP2/#securitypolicyviolationevent

Посмотрю, спасибо

ребяты а есть какой-нить листенер на anchor? надо стейт менять в аппе... plain javascript желательно ))

eventemitter3

https://github.com/developit/mitt

Какие нынче шаблонизаторы в почёте?

pug/jade?

Спасибо, сейчас посмотрю. Нужно чтобы можно было на странице воткнуть json и на его основе описать шаблон, ну превью посмотреть. Пока что лучше всего выглядел Transparency

Ребят, есть кто работал с амоСрм? нужна небольшая доработка

Ребят, есть кто работал с амоСрм? нужна небольшая доработка

только не спамь во всех чатах...

только не спамь во всех чатах...

нужен специалист

еще про orm. эта штука вполне норм выглядит https://github.com/typeorm/typeorm

pug/jade?

pug

еще про orm. эта штука вполне норм выглядит https://github.com/typeorm/typeorm

хы на es6 вот эт уже интересно

нужен специалист

-Как тебя зовут? -..... -Ты тормоз? -Меня зовут Илья. -Как пройти к метро? -Я не тормоз.

еще про orm. эта штука вполне норм выглядит https://github.com/typeorm/typeorm

хорошая штука

только вот на декораторах, как-то не айс

pug

хы

прикольно

таки я за handlebars

таки я за handlebars

меня он пугает...

меня он пугает...

а меня пуг

ну то есть совершенно не нужный уровень абстракции

ну то есть совершенно не нужный уровень абстракции

на сервере использовать handlebars я бы не стал на клиенте возможно, как раз из-за "нативности"

ну да, но если данные приходят с сервера, я бы юзал twig

на Php?

серьезно?

что плохого?

на чём должен работать бэк?