При этом на фронте у меня есть нужный интерфейс и я не ошибаюсь на фронте, т.к. TS мне подсказывает это

В сущностях самое интересное - публичный интерфейс, а все данные должны быть инкапсулированы

На клиенте вас наоборот интересуют данные, а вот публичный интерфейс ваще не особо

Чего я ожидаю. Хочу описать такую модель для ORM : import {Entity} from "typeorm"; @Entity() export class Tag { @Column() id: string; @Column() name: string; } При этом импортить Tag на клиенте и иметь подсказки что если у меня что-то есть Tag[], то в filter у меня доступны только св-ва id & name и они таких то типов

Чего я ожидаю. Хочу описать такую модель для ORM : import {Entity} from "typeorm"; @Entity() export class Tag { @Column() id: string; @Column() name: string; } При этом импортить Tag на клиенте и иметь подсказки что если у меня что-то есть Tag[], то в filter у меня доступны только св-ва id & name и они таких то типов

Вы хотите сущности как dto использовать? Это большая боль на сервере

сори с терминами не очень. трогал php Doctrine кажется лет 10 назад когда еще паспорта не было

https://github.com/typeorm/typeorm#creating-and-inserting-a-photo-into-the-database

Чего я ожидаю. Хочу описать такую модель для ORM : import {Entity} from "typeorm"; @Entity() export class Tag { @Column() id: string; @Column() name: string; } При этом импортить Tag на клиенте и иметь подсказки что если у меня что-то есть Tag[], то в filter у меня доступны только св-ва id & name и они таких то типов

В доке typeorm разве не сказано все поля приватными делать ?

в моём идеальном мире хотелось бы такого примерно, например

в менее идеальном хотелось бы просто shared-models и хотя бы TS на сервре =)

хоть без ОРМ

но это кажется совсем изи решается

но вспомнился ОРМ вчера часа в 4 ночи, вот я и озадачился

я не смогу получить на сервере то что я кинул выше?

<гуглит dto>

не DTO это как-то сложно

в моём светлом мире за await photoRepository.save(photo); инсерт который я не хочу писать

мир что - сложнее?

то есть в моём случае (у меня все достаточно просто-просто) я делаю запрос, обрабатываю его expressjs-ом например (на данный момент так).

делаю импорт нужной модели и юзаю что-то вроде: xRepository.save(x)

@mkusher ? =)

Сорян, перестал читать. Короче typeorm это оверкилл, просто пошарь папочку между клиентом и сервером, где сложишь типы ответов сервера

да да это будет работать 100%

а ОРМ чем плох?

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

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

я

@vladsharikov Странную кашу вы варите, лучше посмотрите в сторону firebase или meteor. TypeScript вам не нужен.

тайпскрипт улучшит dev experience?

почему такие выводы?

вы разобрались в том что я хочу?

Где-то выше описывал проблему.

Вы сказали что хотите использовать одни и теже типы на сервере и на клиенте.

Повторюсь. Вот пишу я на firebase что-то. Деплою . Получаю ошибку.

Выясняется что ошибка из-за того что я написал tagsIds, а не tagIds.

На фронте у меня нет таких ошибок, т.к. есть TS. он не даёт заюзать неправильные св-ва. есть IDE, которая благодаря TS понимает какие конкретно свойства есть вот у того с чем я работаю

это первая часть хотелки.

у меня как раз firebase на данный момент.

но оно мне сильно не помогает.

я уже пишу и уже огребаю

Не панятна мнэ )))

по-моему TS решит эту проблему. разве нет?

flow еще решит

как непонятно. что вам непонятно?

Зачем вы используете модель на клиенте и на сервере?

вот на беке у меня сейчас везде тип any и мне позволено косячить

Это все такие разные контексты

Модель. Что есть модель? Что я сейчас использую на клиенте. export interface DiaryEntry { $key?: string; id?: number; createDate?: {}; date: {}; tags?: Tag[]; message: string; } Модели у меня нет на данный момент. И не хочу. Незачем. Есть интерфейс.

Вот чтобы мою хотелку реализовать я могу тупо заимпортить вот это на сервере. Будет работать подсказка по типам.

Решит мою первую проблему, согласны?

Про dev exp

Давайте пример проще: export interface Tag { $key?: string; name: string; description?: string; } ?

Я видимо не очень фронтендер) Вот и не понимаю, сорян :D

Вот я заимпорчу ровно тот же самый тег на беке - и получу свою хотелку и всё будет работаь. Это всё было про первую часть.

Это вы тролите или правда?

Я дал скрины

Я сказал что у меня есть на фронте и чего хочу получить на беке. Сказал как я это получу.

еще например. в раскрытом списке видим нормальные подсазки.

Я видимо таким просто никогда не занимался. У меня либо есть отдельное клиетское приложение, отдельное серверное, они обычно общаются через кучу слоев, фронт вообще не знает о моделях на беке и не должен. Либо это MEAN типа приложение, где с помощью магии дается возможность взаимодействовать как с одним приложением.

вот я ща просто упороться чуть чуть решил

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

грех не пошарить. у меня всё на JS. почему нет? вернее фронт у меня на TS. и я понял что зачем огребать ошибки на беке, которые можно не огребать? и которые я не огребаю на фронте.

>Либо это MEAN типа приложение, где с помощью магии дается возможность взаимодействовать как с одним приложением у MEAN все как у тебя, никакой магии там нет

это прям изи решается через шаринг вот этих вот интерфейсов.

может ты про Метеор?

это всё же немного другое

Тогда смотрим MEAN(mean, meteor)

в правильном MEAN ты монгу в принципе можешь заменить на что угодно

и ангуляр тоже

просто это такой стек технологий который удобно работают друг с другом

И сам MEAN

да

типа монгу на sql, express на koa, angular на react

ну и нода это последняя инстанция

Да - неправильно сказал, MEAN это другое

@vladsharikov http://img-fotki.yandex.ru/get/6700/35340376.f9/0_facfe_46f0772c_orig.jpg

рукалицо

серьезно?

что зачем? =)

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

Для фронта интерфейс это api сервера

а вы хотите сделать клиент слой для обращения к серверным моделям на фронте?

я вам одно, вы мне другое

забудьте про typeorm

или orm

или вотевер

еще раз. const promises = diaryEntries.map(diaryEntry => getTagsByIds(diaryEntry.tagIds, req.user.uid) ); Есть вот этот код. Вчера тут была ошибка: diaryEntry.tagsIds, req.user.uid tagsIds.

должно быть tagIds.

внимание вопрос: почему я по вашему не сделаю такую ошибку на своем фронте, где я использую typescript?

я думаю вот почему. на фронте у меня тайп скрипт и у меня есть описание интерфейса: DiaryEntrySet. И там четко сказано, что должно быть поле tagIds типа string[].

не tagsIds, а tagIds. Теперь когда я написал некий нерабочий код ts-compiler мне скажет “эй друг, тут у тебя косяк, я не собирусь”

это всё про фронт.

еще вопрос: зачем мне огребать эти детские проблемы js-ные , когда я могу в 2 команды прикрутить tsc к моему бекенду (он на javascript, firebase) и написать:```const promises = diaryEntries.map(diaryEntry: DiaryEntrySet => getTagsByIds(diaryEntry.tagIds, req.user.uid) );```

Ипортировав при этом DiaryEntrySet откуда-то из общей части