Вью в будущем выстрелит больше

как знать…
под реакт уже столько инфраструктуры, UI китов и всего чего только можно представить (хотя я не особо фанат реакта), мне очень слабо верится что vue3 займет какое-то ощутимое место в картине будущего фронтенда

хотя бы (!) догнать позиции vue2

Смотря какой курс они выберут. Вполне вероятно что реакт будет обрастать и обрастать всякимими мидварами, хуками, стораджами, модификаторами и пр херней, что в конце концов сделает из него какую чрезмерно громоздкую хрень, что приведёт к падению использования на новых проектах. Когда сложность настройки и учёта всех особенностей будет превышать удобство готовых заготовок

я в это слабо верю.. при всей моей любви к ангуляру я вижу куда пришел ангуляр и куда идет реакт

вряд ли как-то кардинально изменят картину “Хуков”, они уже и так максимально навороченные насколько это возможно

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

Каждое следующее поколенин фронтовых либ все сложнее и тяжелее, кто начнет упрощать - прорвется через весь этот бред

Вілл сі, зараз працюю з реактом і здається що це просто і зручно )

А куда пришёл ангуляр? Что имеется в виду? Если что, я вообще не в теме, фронт не моё, но в прошлый раз ты очень убедительно обосновал преимущества ангуляра, и я для себя сделал вывод, что если когда надо будет делать фронт (надеюсь, этого не будет), то выберу ангуляр

Адепты ангулар и нэст

да, говорил так.
К ангуляру я все еще испытываю теплые чувства, но я столкнулся с несколькими задачами в последнее время.

1) у нас в компании есть легаси проект (написанный еще на ангуляреЖС 1.5), не маленький проект, и в нем надо было расширять функциональность, дописывать новые компоненты/контейнеры. Продолжать развивать кодовую базу на старом фреймворке - выстрел себе в ногу ибо это только увеличивает время в будущем на миграцию проекта (которая неизбежно должна быть). Потому после некоторого ресерча я сделал нечто вроде микрофронтенда - оборачиваю реактовый компонент ангуляровской директивой и вкраплениями вставляю самостоятельные контейнеры в страницу. Для этого реакт очень хорошо подошел - он очень маленький с очень предсказуемым однопоточным дата-флоу. Вписалось отлично и работает.
К тому же, мне удалось настроить вебтак так хитро, что вся кодовая база реакта пишется на тайпскрипте, и вкраплениями вставляется в JS файлы. Все в гармонии и процветании.

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

2) делаем внутри компании новый проект, времени на дизайн нет, потому берем готовый UI kit.. и смотрим. Под реакт - blueprint, antd, material UI, fluent UI и куча другого (да, под ангуляр тоже ессть материал, ng-zorro, но последний очень отстает в развитии, хотя вот пол месяца назад релизнули уже соответствующую версию чтобы догнать реакт).
Плюс, надо было реализовать свою spreadsheet, начал ресерчить что есть под ангуляр - там либо платные коммерческие либы за очень много денег, либо ни-че-го. Под реакт - тонна интересных (и не очень) поделок, которые можно в пол движения руки допилить и получить не кислый результат.

В общем после этого всего я вынужден признать что реакт-экосистема превосходит все что есть вокруг (человечество больше всего в рамках именно этой экосистемы скопило наработок).
Ну и плюс, я не работал с реактом уже полтора года, когда я уходил - меня задолбал бойлерплейт классо в компонентах. Но сейчас.. хуки, эффекты, провайдер (контекст) - меня приятно удивило на сколько просто и легко можно делать компоненты, все очень упростилось, особенно чудесный react-hook-form  и довольно лаконичный (уже хоть как-то дотягивает до уровня ReactiveForms у ангуляра, хотя все же последний будет лучше).

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

Хочешь сказать, что это не удобно? Особенно, когда всё в одной монорепке лежит)

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

А можно вопрос по первому пункту? Почему считаете что миграция с 1.5 версии неизбежна? У нас просто бизнес считает что это не оправданная трата ресурса и очень сложно им доказать целесообразность такой миграции...

я очень просто это аргументировал

1) свежая модерновая экосистема обростает как правило только вокруг популярных современных фреймворков. Простейший пример: нам надо был spreadsheet (по типу экселя), под реакт их чуть больше чем много. Под ангуляр ЖС выбора в принципе нет.
Нам в любой момент может (и надобится) иногда какой-то новый модерновый функционал, под старый ангулярЖС мало того что в будущем сложно будет найти разработчика, так еще и придется любую прихоть писать с нуля самому, а под реакт всегда можно найти уже либо готовый законченный продукт, либо неплохую поделку и доделать самому.

2) мне в принципе не пришлось убеждать в миграции, мы просто новый функционал пишем на реакте и вставляем контейнерами в старый ангуляр. В момент, когда “нового” кода будет около 70-80%, тогда будет очень безболезненно переписать оставшиеся устаревшие модули и полностью перейти на реакт

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

Спасибо за ответ ) А что это за волшебная техника с контейнерами? Про нее где то можно почитать?

Я собирал по крупицам… но в общем картина выглядит примерно так:

import ReactDOM from 'react-dom';
import React from 'react';

function toBindings(propTypes) {
  const bindings = {};
  Object.keys(propTypes).forEach((key) => (bindings[key] = '<'));
  return bindings;
}

function toProps(propTypes, controller) {
  const props = {};
  Object.keys(propTypes).forEach((key) => (props[key] = controller[key]));
  return props;
}

export function reactToAngularComponent(Component) {
  const propTypes = Component.propTypes || {};

  return {
    bindings: toBindings(propTypes),
    controller: /*@ngInject*/ [
      '$element',
      function ($element) {
        this.$onChanges = () => {
          const props = toProps(propTypes, this);
          ReactDOM.render(<Component {...props} />, $element[0]);
        };
        this.$onDestroy = () => ReactDOM.unmountComponentAtNode($element[0]);
      },
    ],
  };
}

потом просто делаешь angular.component(‘mySuperComponent’, reactToAngularComponent(MySuperComponent));

ну и в тимплейте уже <my-super-component></my-super-component>

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

Круто, спасибо большое за ответ )

господа, ща будет тупой вопрос...
Есть запрос, к примеру такой

DECLARE p_key VARCHAR2(255);
BEGIN
insert into TOYS (TOY_ID, TOY_NAME, COLOUR) VALUES (17, 'Test3', 'Red') RETURNING TOY_ID INTO p_key;
END;

но при выполнении p_key не возвращается. Его как-то нужно запросом просить?

как вы выполняете этот запрос? какую функцию какой библиотеки вызываете? там бывает нужно явно указать что “не просто выполни этот запрос а верни то что он вернет”

ничего не возвращается ни через knex.raw(...) ни в консоли бд

вообще задача - вернуть последнюю добавленную запись, или строчку, или праймери ключ, хоть что-то... Но ничего не могу придумать... БД - OracleDB