Как идёт строительство The Line, города будущего в пустыне

Я думаю вы поняли о чем я, возьмете квартал с застройкой в 5 этажей и переверните на 90 градусов, поставьте таких кварталов один на другой в высоту 500 метров или сколько там планируется, и вряд ли это будет сильно отличаться в плане обслуживания от привычных кварталов, в этом случае например можно будет лучше организовать мусоропроводы, в самом низу будет один большой контейнер для сбора, наверху не будет ничего накапливаться и т.д.

Как идёт строительство The Line, города будущего в пустыне

Так тут будут такие же кварталы только не в плоскости х а в плоскости у, я вижу это как район Эшампле в Барселоне только в другой плоскости

Директор директив. Расширяем функционал angular-компонентов красиво. Директива-контекст

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

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

Правила хорошего тона на Angular

Статья же про ангуляр, поэтому оценка в рамках ангуляра
Много спорных пунктов, и очень уж устарелой информации

1. "Ограничение на длину метода: 150 строк." - это очень много, до 50 строк максимум, и даже 50 уже прочитать сложно

2. "Пользуйтесь покомпонентами Angular Material." - Много UI библиотек и Material не лучшая из них

3. "Роуты отдельного модуля в RouterModule.forChild" - С standalone компонентами это немного неактуально

4. "Структура модуля" - Чаще всего эти папочки избыточны

5. "NgRx - желателен (очень)." - Сомнительный совет, куча бойлерплейта и потраченого времени

6. "API должно быть гибким." - Api чего? Если для работы с бекендом, то это зависит от бекенда

7. "Данные должны быть разделены на чанки." - Что тут имеется ввиду? Данные приходят с бекенда, и как сделали апи, в таком виде данные и придут

8. "Расширяйте код при помощи прототипизирвоания" - В Ангуляре? Как вы это видите?

9. "Использовать monent.js " - Даже разработчики уже не рекомендуют его использовать

10. "Использовать JSDoc" - Коментарии нужны только там где сложно прочитать написаный код, писать коментарии ради коментариев очень плохой совет

Написание слоя API в приложении — это прошлый век! Встречайте универсальный прокси

Вот вам более явные примеры как это предлагается делать в случае с прокси в сравнении с каким-то класическим способом описания апи

// Client with Proxy implementation
function api<T extends {}>(): T {
  // Proxy implementation
  return null;
}

export interface UserApi {
  getUser: (id: number) => Promise<any>;
  getUsers: () => Promise<any>;
  addUser: () => Promise<any>;
  updateUser: (id: number, payload: any) => Promise<any>;
}

export interface StoreApi {
  getStore: (id: number) => Promise<any>;
  getStores: () => Promise<any>;
  addStore: () => Promise<any>;
  updateStore: (id: number, payload: any) => Promise<any>;
}

const userClient = api<UserApi>();
const storeClient = api<StoreApi>();

// Common Clients
export class UserClient {
  getUser(id: number): Promise<any> {
    return fetch(`/user${id}`)
  }
  getUsers(): Promise<any> {
    return fetch(`/users`)
  }
  addUser(): Promise<any> {
    return fetch(`/users`)
  }
  updateUser(id: number, payload: any): Promise<any> {
    return fetch(`/users${id}`, payload);
  }
}

export class StoreClient {
  getStore(id: number): Promise<any> {
    return fetch(`/store${id}`)
  }
  getStores(): Promise<any> {
    return fetch(`/stores`)
  }
  addStore(): Promise<any> {
    return fetch(`/stores`)
  }
  updateStore(id: number, payload: any): Promise<any> {
    return fetch(`/stores${id}`, payload);
  }
}

const userClient = new UserClient();
const storeClient = new StoreClient();

Написание слоя API в приложении — это прошлый век! Встречайте универсальный прокси

Вы приписываете мне то что я не писал, я нигде не писал что надо тестировать класс из первого коментария или что-то подобное, я конкретно писал про тестирование прокси и все.
И что в первом коменте что дальше я писал про разницу в простоте между просто интерфейсом и классом(функцией) с каким-то дополнительнім кодом
Тестировать все это на возвращение объектов определенного типа собирался товарищ что отвечал мне на коменты
В моих коментах нет ничего кроме тестирования прокси что он правильно работает и все, никакие тесты не нужны больше

Что касается вашего примера выше, так вот:

Для реализации с прокси вам этот кусок кода вообще не нужен, будь это класс, функция или просто объект, неважно как вы хотите это реализовать, это попросту не нужно

let client: API = { ... + async postNewMethod(param) { + return await this.post('/new-method', { param }); + } }

Написание слоя API в приложении — это прошлый век! Встречайте универсальный прокси

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

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

Написание слоя API в приложении — это прошлый век! Встречайте универсальный прокси

Какое другое поведение? Что вы хотите там еще протестировать? Слой апи отвечает за то что получает какие-то входящие данные идет с ними на сервер и возвращает ответ, все то же самое, просто тут описание апи идет за счет интерфейсов без написания дополнительной логики
Если у вас есть какие-то трансформации данных от сервера то это перейдет на другой слой и будет тестироваться там

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

Написание слоя API в приложении — это прошлый век! Встречайте универсальный прокси

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

Написание слоя API в приложении — это прошлый век! Встречайте универсальный прокси

Ну тестируется ведь только какая-то ло логика, а тут вся логика состоит в том что нужно трансформировать названия вызываемых методов в url path, Это тестируется один раз и больше не меняется
А потом только описываются интерфейсы которые тестировать не надо, потому что нечего там тестировать
В целом идея того что бы описывать таким способом апи очень даже интересная, но это немного смахивает на магию если не будет написано документации на то что происходит

Написание слоя API в приложении — это прошлый век! Встречайте универсальный прокси

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

Реализация один раз написана, покрылась тестами и больше вы ее не трогаете, а расширяете свой cdk только за счет описания новых интерфейсов

Написание слоя API в приложении — это прошлый век! Встречайте универсальный прокси

Я так понимаю вы придумали CDK. Пусть внутри оно работает на основне прокси, но для клиента который это использует вообще нет никакой разницы как оно реализовано внутри. Интересная идея трансформации названий методов в url path, но я вижу упрощение только в этом.

В остальном все равно придется писать еще один слой для работы с этим cdk и получается что теперь есть прокси слой который пишет бекенд + слой на клиенте который будет работать с этим cdk вместо одног api слоя на клиенте.

Все же я больше профита вижу в том что бы бекенд хорошо описывал openapi документацию а клиент на основе этого генерировал себе все что ему нужно

Я счастлив, что больше не веб-разработчик

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

Почему нет протестов против безответственной политики удаления неактивных аккаунтов?

Так может в этом не Эппл виноваты? Как обычно вы смотрите не на первопричину а на результат

Почему нет протестов против безответственной политики удаления неактивных аккаунтов?

Вот только не Гугл пользуется вами, а вы гуглом, и взамен на это он вам показывает рекламу, а вы взамен на это с большой долей вероятности пользуетесь блокировщиками рекламы, и очень вряд ли откажетесь от этого

React vs Vue vs Angular. Часть 3

Любой front-end разработчик который не знает ни один из єтих фреймверков, посмотрев на представленные компоненты сможет хоть что-то разобрать в Angular, React, Vue компонентах, в вашем же случае без курения документации ничего понять невозможно

Почему я не буду использовать Next.js

Это что-то вроде laravel + Blade или любой другой фреймверк с шаблонищатором? Вроде ж как давно разработка идет в сторону от монолитов.
А тут же выходит так что бекенд и фронтенд завязаны друг на друге по самое немогу, и если появится потребность заменить либо фронтенд либо бекенд то это не выйдет, надо буде переписывать полностью все
Или может я не так понимаю концепцию Next.js?

Добро пожаловать в ренессанс Angular: представлена 17-я версия

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

Как сделать декларативный роутинг диалогов в Angular на примере Taiga UI

this.router.navigate([{ outlets : {dialog : null} }]);

Этот код закрывает диалог и не влияет на основной роутинг
т.е. в итоге от /home(dialog:login) остается /home


Как сделать декларативный роутинг диалогов в Angular на примере Taiga UI

Можно ведь еще проще, через именованые роуты делать
Для моих задач никаких минусов в этой реализации небыло
Навигация отдельная, можно с любого места открыть любой диалог, вынести это в ленивый модуль
Возможно только может смущать нестандартный вид url
Что-то такого вида /home(dialog:login)
При том не нужны никакие костыли в виде backUrl и т.п.

Базовый пример

app.component.html

<router-outlet></router-outlet> <!-- Для основных страниц -->
<router-outlet name="dialog"></router-outlet> <!-- Для диалогов -->


app.routing.ts

// Пример роутинга
RouterModule.forRoot([
  {
    path: "home",
    component: HomeComponent,
  },
  {
    path: "login",
    outlet: "dialog",
    component: LoginComponent,
  },
  {
    path: "registration",
    outlet: "dialog",
    component: RegistrationComponent,
  },
]),

// Пример навигации
// Это не влияет на основной роутинг
return this.router.navigate([{
  outlets : {dialog : ['/login']}
}]);

// Кажется даже так можно, т.е. роутер аутлетами можно управлять по отдельности
// И они не влияют друг на друга
return this.router.navigate(['/home', {
  outlets : {dialog : ['/login']}
}]);

// А если вы так сделаете, а при этом у вас открыт диалог
// то основная страница поменяется, а диалог все так де висеть будет
return this.router.navigate(['/home', {
  outlets : {dialog : ['/login']}
}]);

�