всё на этом первая часть закончела. хотелка достигнута. на беке есть тоже поддержка типов и типы шарятся между беком и фронтом. 1 раз написаны - красота.

вы хотите писать без TS - пишите. или скорее всего ваш бек вообще не на JS и тогда и говорить не о чем конечно же.

и тут меня занесло в ОРМ, т.к. я подумал “стой было бы круто…"

и вот курю в сторону typeorm и соображаю можно было бы….

но это уже совсем другая история

А почему у вас типы на фронте и беке совпадают?

@vladsharikov я тебя предупреждал что тут начнётся %)

Безусловно они не полностью совпадают. Частично совпадение есть. Например у меня есть объект который возвращает бек: {items: Tag[]}. У меня есть Тег. И он блин совпадает.

На беке я фильтрую массив

Сортирую массив

Мне помогут подсказки по св-вам

Например у меня есть interface TagsRequestFilter {query?: string}

И он тоже одинаковый и там и там

Я конкретно о той части бекенда которая крайняя и которая взаимодействует с фронтом

Что там внутри у бека - отедльный разговор.

Там свои классы и своя кухня и т.п. и т.д.

Я лишь о том небольшом слое что обрабатывает запросы и возвращает ответы.

вот эта часть частично местами общая.

Слой отображения(контроллеры)?

Да, наверное для API это будет слой отображения.

https://github.com/sharikovvladislav/ng2-diary-book-backend/blob/master/functions/diary/get-my-diary-entries.js#L7

Кстати этот же файл хорошо пояснит чем мне неугоден nosql и почему хочется норм БД реляционную

если бы была такая я бы решил дело простым селектом.

и вот тут дальше мне в голову пришла мысль что о! орм! было же круто тогда в школе? можно и сейчас попробовать!

Ну можно наверное и там и там использовать этот интерфейс, проблем нет. Но я бы не стал, тк интерфейсы на мой взгляд должны располагаться в том месте где они нужны, например при DIP.

и вот я говорю с вами сейчас =)

можно использовать. и у меня вся логика в общем-то в этом слое сосредоточена (ни в коем случае не претендую на правильность и тп). поэтому неплохо тут не косячить так глупо.

вот сейчас разработка фронта - рай, разработка бека - ад. если бы я не редеплоил проект так много вчера я бы ушёл спать в 2, а не в 4 =)

Не думайте о моем фронте-беке как о чем-то мудрёном и сложном. Всё проще некуда. Фронт Angular. Бек firebase. Прослойка между фронтом и беком: REST API. Бек: express обрабатывает эти запросы, работает с firebase ref и что-то оттуда возвращает (или добавляет или whatever). Всё просто просто. Очень маленький проект.

Если клиент и сервер разные приложения. То к примеру если вам нужно поменять для сервера этот объект-интерфейс, то получается что он измениться и для фронта, хотя для фронта он не должен меняться.

Как же так?

Смотрите, я поменяю Tag.

Добавлю туда еще обязательный description.

Почему на фронте я не должен о нём знать?

Тогда у вас не ДВА приложения, а ОДНО.

У вас нет границы получается.

Мы просто добавляем (или удаляем, изменяем) какое-то поле.

Но погодите. Пусть будет два.

Вот отлично

Вы на сервере (бекендщики злые ага) удалили поле name из Tag

Поэтому вы и делаете что то похожее на метеор

у вас есть X API ф-ий которые я (светлый воин фронтенда) вызываю

и тут внезапно вы такие не отдаете то на что у меня завязки много где есть.

1 момент, покажу

Суть в том что этих завязок и не должно быть.

Фронт не зависит от моделей на бекенде

фронт зависит от api

это граница

У меня появились такие ошибки: ERROR in /Users/svlad/dev/ng2-diary-book/src/app/diary/containers/entry-create-container.ts (29,7): Type '{ date: Date; message: string; tags: undefined[]; }' is not assignable to type 'DiaryEntry'. Object literal may only specify known properties, and 'date' does not exist in type 'DiaryEntry'. ERROR in /Users/svlad/dev/ng2-diary-book/src/app/diary/services/diary-entry.ts (41,23): Property 'createDate' does not exist on type '{ $key?: string; id?: number; message: string; }'.

Как не должно быть зависимостей.

Окей поясните мне как правильно.

Да на самом деле я от вас получаю просто JSON

Нет правильно или неправильно

Так вот у вас нет границы, а страдают конечные пользователи

я просто говорю что у вас получается одно приложение

Потому что у них потом будет написано : нельзя прмиенять метод фильтр на undefined (tagIds какой-нибудь)

и это похоже на метеор

потому что бек его не прислал

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

при раздельный приложениях, бек работает с моделями, он не должен отдавать эти модели

повелевать фронтендщикам “так ребят вы тут разберитесь в логах, ошибка то на морде, а мы пока новые фичи попалим”

Да раздельное раздельное) Но как бы оно одно. Оно должно в целом работать.

Вот даже простейшая хотя бы вещь. ТайпСкрипт мне помогает не накосячить на фронте или на беке. Почему бы не использовать это?

Тогда вы делаете одно цельное приложение front+back, вы пытаетесь сделать такую же магию как метеор

но я такое не юзаю, так что дальше помочь не могу)

Так и хорошо. В чём проблема?

Ага. Вы же тот самый злой бекендщик и “у вас ошибок нет” :troll: ?

Нет никаких проблем, я вас в самом начале и посоветовал просто посмотреть на метеор)))))

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

На самом деле пока мы говорили прикинул прототип общей модели. Огонь же. Минимально необходимое - подстветка - работает и правильно работает. Мой мир стал чуточку лучше ?. Но typeorm вопрос будет открыт =) Но после курения метеора. Ща давайте спать.

Мне еще работать)

Надеюсь вы просто из Владивостока и у вас 8 утра ?

Nope - Moskva never спать

Тогда вы делаете одно цельное приложение front+back, вы пытаетесь сделать такую же магию как метеор

или Java EE

я имею ввиду там тоже все и фронт и бек

https://medium.com/web-on-the-edge/thinking-in-typescript-cb7f8a6434c0

https://medium.com/@paul.souche/one-word-about-typescript-control-flow-and-union-types-discrimination-fc2cb1095d93?source=linkShare-60d353fea4d-1507015134

>inference in typescript

Статья ниочем

Вижу что в @types есть указание версии typescript для которой типы написаны. А как то можно эту инфу использовать при установке типов?

обновление до ts 2.5 это боль :(

фигачить селекты как-то не оч?

орм это инструмент для решения другой задачи на другой границе. У вас проблема на границе клиента и бекенда, а орм - решение проблемы на границе бекенда и хранилища(рсубд)

@mkusher я описывал 2 проблемы

Одна из проблем на границе

И ее решить без ОРМ можно без проблем

А ОРМ - да, решение проблемы между беком и БД - всё так.

@mkusher я описывал 2 проблемы

видимо я заблудился при чтении и пропустил это

Теперь если создаёшь jsx элемент через функцию-фабрику, лишние пропы являются ошибкой. А если через jsx - нет. Как то это... неконсистентно.

Это в типах?

точнее даже не так: если использовать спред-оператор, то лишние пропсы которые он добавляют считаются лишними на object literals, но не считаются таковыми в jsx

Товарищи. Есть некий nodejs модуль. Хочется добавить TypeScript. Сейчас в модуле написано: module.exports = function (x) {} Как сделать export в TypeScript так, чтобы это было преобразовано в module.exports?

export = function () {}

не уверен что работает где-то кроме деклараций

я бы ес модули заюзал

работает

я бы ес модули заюзал

import/export?