У неккоторых людей слишком много свободного времени

в го дженериков нет, не подойдет)

http://bepsays.com/en/2016/10/13/react-in-go/

Лучше на сишарпе

https://youtu.be/-03R4Fj79_E

hot reload 200ms

сколько у вас там на TS incr. build time?

hot reload 200ms

это Dart?

да

https://github.com/flutter/flutter

Дарт обещает strong mode

Это уже интересно

боже dart храни

EdgeInsets.symmetric .... какие-то очень интересные велосипеды :/

Вау! Вижу кол-во участников растет очень стремительно. Наверное тайпскрипт уже очень много людей используют.

Здесь ещё и про флоу

и про Dart

опять откопали

о, @Ai_boy, вчера смотрел твое выступление про SOLID в js и очень прям несогласен с твоей трактовкой DIP и его связью с IoC. Если я ща ошибаюсь, то смело исправляй. 1. Inversion через s :) 2. DIP и IoC действительно не одно и тоже, IoC(и как частный случай dep inj) это конкретный механизм(паттерн или еще как-то), который описывает каким образом мы избавляемся от зависимости. Если мы применили IoC это еще не значит, что мы стали соблюдать DIP. DIP говорит нам не привязываться к конкретной реализации. Как верно ты заметил в статических языках оочень сильно видна разница - если мы зависим от конкретного класса/реализации, то мы проиграли(= не соблюдаем DIP). В js интерфейсы просто неявные, мы также можем начать зависеть от конкретной реализации и проиграть

@mkusher сори.. а с чем ты не согласен :) ибо я тебя прочитал и мне кажется мы об одном и томже говорим. Может мне не удалось все удачно разложить по полочкам но именно это я и пытался донести есть общая проблема Dependency которая решаеться с помощью общего подхода Decoupling. Decoupling (избавление от зависимостей) - Inversion of Control (принцип) -> ( Dependency Injection ) (способ реализации принципа - дизайн паттерн) - Dependency Inversion (принцип) -> ( Interfaces ) (способ реализации принципа)

inversion

IoC это один из возможных механизмов добиться DIP

или подходов

но его применение не дает автоматически выполнение DIP

потому что вот твой вариант с interfaces это один из вариантов dependency injection

а не inversion

Раз уж заговорили

https://github.com/inversify/InversifyJS

Кто юзал?

https://github.com/inversify/InversifyJS

Мы юзаем активно для E2E тестов на TS - работает отлично

потому что вот твой вариант с interfaces это один из вариантов dependency injection

Dependency Injection - это дизайн паттерн который реализует IoC.

не спорю

я не могу понять в чем мы с тобой не согласны :)

Decoupling (избавление от зависимостей) - Inversion of Control (принцип) -> ( Dependency Injection ) (способ реализации принципа - дизайн паттерн) -> ( Interfaces ) (способ реализации принципа)

еще она может быть как в ангуляре

по имени параметра

или там по декораторам

ну и еще куча других вариантов

Не не не. Я понял ты путаешь Dependency Injection и Dependency Inversion - это сильно разные вещи

не invertion

а inversion

DIP вообще к интерфейсам или типам или даже классам отношения не имеет

https://en.wikipedia.org/wiki/Dependency_inversion_principle

короче, DIP про то, чтобы перестать зависеть от одного, а зависеть от чего-то другого. И не просто так, а потому что получится гибче. Мы не зависим от low-level(я называю их реализации), а зависим от абстракции(явные или нет). Для этого мы можем применить DI(который injection) по интерфейсам

короче, DIP про то, чтобы перестать зависеть от одного, а зависеть от чего-то другого. И не просто так, а потому что получится гибче. Мы не зависим от low-level(я называю их реализации), а зависим от абстракции(явные или нет). Для этого мы можем применить DI(который injection) по интерфейсам

Мы можем применять DInjection по интерфейсам - но то что позволяет нам избавиться от зависимости сдесь это Interface.

мы можем любой DI для этого применить, но само его применение может не дать выполнение принципа. Если наш сервис зависит(не важно получает через конструктор, параметр или импортит) от superagent api/fetch, то будет, скорее всего, нарушение принципа

интерфейс не сам по себе

мы можем любой DI для этого применить, но само его применение может не дать выполнение принципа. Если наш сервис зависит(не важно получает через конструктор, параметр или импортит) от superagent api/fetch, то будет, скорее всего, нарушение принципа

да согласен. Вот в этом и суть поэтому это 2 разных принципа - их конечно можно применять вместе - но они всетаки разные. Тут соглашусь в том что грань очень тонкая.

если мы заюзали интерфейс, который экспортит moment например, то мы все еще зависим от low-level пусть и интерфейса

DIP и IoC

да согласен. Вот в этом и суть поэтому это 2 разных принципа - их конечно можно применять вместе - но они всетаки разные. Тут соглашусь в том что грань очень тонкая.

IoC скорее конкретный механизм decouple

с несколькими реализациями

который позволяет добиваться выполнения DIP

который позволяет добиваться выполнения DIP

Но согласись что DIP поможо добиться и без IoC ?

конечно

а с помощью IoC можно остаться зависеть от low-level

они разные, но ты показал только интефейсы, которые вообще часть dep injection

они разные, но ты показал только интефейсы, которые вообще часть dep injection

Интерфейсы можно использовать в Dependency Injection и в Dependency Inversion Principle они сами по себе. Смотри что я пытался сказать - можем мы делать IoC без DIP ? да, можем мы делать DIP без IoC? да. Вот поэтому я их и "разделил". По факту это все часть одной большой концепции и перемешать все это можно как угодно.

не, я к разделению ничего не имею

ты примеры больно плохие приводил

сейчас

https://youtu.be/wi3wPzReKZQ?t=35m35s

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

но вот пример, что такое DIP, что это вот интерфейс, ну вообще никуда не годится

ERROR: S client not available

и что в js он не нужен тоже)

ты примеры больно плохие приводил

То что я не смог привести хороший пример - не отменяет правильности принципов. У меня нет цели доказать что я лучше всех все знаю. Это не так. У меня была цель познакомить людей с SOLID - очень много людей даже не слышало об этом всем.

ха, да, я ж не говорил, что принципы неправильные :))

но DIP в js есть, знать его надо. IoC тоже есть и dep inject есть, но не по явным интерфейсам, да

но DIP в js есть, знать его надо. IoC тоже есть и dep inject есть, но не по явным интерфейсам, да

Ruby ребята называют это "контрактами" - мне кажется идеальное слово. У твоего обьекта в динамическом языке есть некий "контракт" соблюдая который ты получишь - ожидаемое поведение.

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

ты не только сохраняешь public api в плане типов и имен методов, но еще и поведение не меняешь

list.add не начинает делать удаление там или двойное добавление

интерфейсом такого не описать, отсюда и принцип Барбары Лисков)

Не спорю, но "контракт" мне нравится больше. Хотя может и не идеальное слово. В это плане я за ребят из Ruby (у них ровно теже проблемы в плане динамичности языка и отсутствия интерфейсов)

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

в общем остановимся на том что примеры у меня были не совсем удачные, SOLID рулит и бибикает и в JS нет явных интерфейсов но есть "контракты".

нет явных интерфейсов!

как может быть контракт и не быть интерфейса))

поправил :) все - пока откланиваюсь (можно будет продолжить какнибудь в другой раз)

а в чем отличие контракта от интерфейса?

@vkurchatkin как объяснить flow, что в типе может не быть некоторых ключей от типа, но не может быть дополнительных?

Для начально нужно объяснить мне так, чтобы я понял

)

просто optional поля не работают?

export type ItemProps<T> = { item: T, hovered: boolean, selected: boolean, isScrolling: boolean }; export type Props<T> = { className?: string, items: IndexedCollection<T>, hover: ?T, selected: Set<T>, itemHeight: number, itemComponent: React.Component<*, ItemProps<T>, *>, onHover: (item: T) => any, onSelect: (item: T) => any };

itemComponent - может не обязательно принимать все ItemProps

но я их обязательно передаю

Чет все равно не понятно. Если не все, то зачем ты их передаешь?

ну кто-то юзает, кто-то нет

ок давай проще

а в чем отличие контракта от интерфейса?

ну, если брать то, что есть у нас в ts/flow или там java, то там мы описываем публичный интерфейс как имена методов, порядок и типы аргументов и тип возвращаемого значения, но не описывается ожидаемое поведение или какие-то ограничения на параметры

есть Array.prototype.map. он всегда 2 аргументом передает index, но почти никто его не использует. тут тот же случай, но тут объекты

ну, если брать то, что есть у нас в ts/flow или там java, то там мы описываем публичный интерфейс как имена методов, порядок и типы аргументов и тип возвращаемого значения, но не описывается ожидаемое поведение или какие-то ограничения на параметры

то есть контракт - это описание поведения? что при вызове get не будет мутации, например?

ну например да

контракт плюс к интефейсу наложит еще какие-то ожидания