lexstile

Этот материал читал.

вроде должно подойти (см. там вариант с useMemo)

только у тебя параметр для мемоизации - не примитивное значение, а объект (position, он же dish). Потому укажи кастомный serializer, который просто возвращает position.id.

в целом способ прикольный, но надо помнить, что в отрендеренном родительском компоненте (в твоем примере - Category) мемоизация будет жить постоянно до размонтирования. И если будут часто меняться ключи, а компонент будет жить очень долго, то в кэше накопится много элементов. На этот случай в опциях fast-memoize можно задать свой кастомный кэш с ограничением на размер и удалением старых элементов. Впрочем, полагаю, в твоем случае до такого не дойдет.

Но как показалось, React.memo можно было избежать.

зачем? здесь оно в самый раз.

а вообще у тебя какая-то хрень в нейминге. По идее, компонент Position должен быть для каждого элемента массива positions. А то что у тебя называется Position, должно называться Dish, и тоже быть memo
т.е. так:

{positions.map(({ id, name, ref, dishes }) => <Position ... />)}

export const Position = memo(({ ...,  dishes, ... }) => {
.........
   {dishes.map((item) => <Dish ... />}
.....
});

тогда при изменении чего-то, например, внутри блюда, будет перерендер компонента со списком позиций, перерендер одной позиции с блюдом, и перерендер блюда.
Это минимум для иммутабельного стейта. Если хочешь совсем упороться и выкинуть перерендер списка, то mobx в помощь.

Порядковый номер, небось, еще и сбрасываться должен каждый год?
Например, можно сделать два запроса: INSERT, при котором id таки назначится нормальным авто-инкрементом, и UPDATE, который заполнит отдельное поле number значением

SELECT count(id) + 1 
  FROM orders 
  WHERE id < :currentId AND project_id = 2 AND created_at >= '2022-01-01'

Никакие гонки это не запутают.
А если этот number нужен только в одном месте, его можно таким запросом получать динамически и не хранить нигде вообще.

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

Все трюки с блокировкой таблицы могут параллизовать ваш бизнес. А зачем вам это надо?

Пример реализации.

-- рабочая таблица
CREATE TABLE orders (
  id INT AUTO_INCREMENT PRIMARY KEY,
  project_id INT,
  project_number INT
  );

-- опорная таблица для генерации номеров в разрезе проектов
CREATE TABLE generate_project_number (
  project_id INT,
  project_number INT AUTO_INCREMENT,
  PRIMARY KEY (project_id, project_number)
  ) ENGINE = MyISAM;

-- триггер-генератор
CREATE TRIGGER generate_project_number
BEFORE INSERT ON orders
FOR EACH ROW
BEGIN
  -- вставить хапись в опорную таблицу для генерации номера
  INSERT INTO generate_project_number (project_id) VALUES (NEW.project_id);
  -- вставить сгенерированный номер в рабочую таблицу
  SET NEW.project_number = LAST_INSERT_ID();
  -- почистить опорную таблицу от лишних записей
  DELETE FROM generate_project_number 
  WHERE project_id = NEW.project_id
    AND project_number < NEW.project_number;
END

DEMO fiddle

Если блокировать таблицу не совпадут.
LOCK TABLES orders WRITE
тут получаем максимальный номер
пишем новый заказ
UNLOCK TABLES

...
$categoriesWithDishes =  $menu
       ->categories()
       ->with('dishes')
       ->get();

Почему костыльно?
Почитайте про sometimes - здесь мы говорим что валидировать если поле есть в теле запроса
Ну и про усложнённую логику валидации.
Скорее всего вам просто нужно вместо nullable, сделать sometimes и тогда вы будете валидировать поле, только если оно есть в запросе.

Нет.

Можно примерно так:

@mixin verticalAlign($screen) {
  @each $direction, $alignment in $alignments {
    &.v-align-#{$screen}-#{$direction} {
      align-items: $alignment;
    }
  }
}

@mixin media($minWidth) {
  @media (min-width: $minWidth) {
    @content;
  }
}

@include media(768px) {
  @include verticalAlign('md');
}

Pivot модель, вложенный ресурсный контроллер с shallow и

public function destroy(OrderDish $orderDish)
{
      $this->authorize('delete', $orderDish);

      $orderDish->delete();

      return back(303);
}

Вообще-то единственное число от dishes - dish, а не dishe.
И добавлять блюда в таблицу совсем не обязательно через $order->attach.
Достаточно создавать их с полем order_id = $order->id, чтобы при выборке они зацепились.
Ну, а как создавать записи пакетом - думаю, вы либо знаете, либо легко нагуглите.

можно без for. attach сразу массив. примеры https://stackoverflow.com/questions/23226802/larav...

Что-то мне подсказывает, что (скорее рано, чем поздно) возникнет задача построить отчет по отказам. В этом случае я бы эту таблицу оставил как есть, но добавил ещё таблицу с отказами, с полями "заказ, блюдо, количество, пользователь, дата".
Из бонусов — в обе таблички данные будут только добавляться, можно подбирать тип БД, который умеет в быструю вставку, с репликацией чуть проще...

На счёт частичной оплаты не понятно — зачем вообще такое, почему недостаточно оплачивать всё и сразу. И зачем отслеживать какие именно позиции оплачены.

Rule::exists('categories', 'id')->where(function ($query) {
            return $query->where(menu_id, $this->menu->id);
        }),

settings-general-Visibility, project features, permissions

Грамотно - не заниматься проверкой прав в модели. Юзать политики авторизации и обрабатывать 403 на фронте. Убрать failedValidation т.к. Ларавел сам составит правильный ответ. Success не нужно, если есть ошибки значит не success. Убрать бессмысленные проверки в rules с одинаковым кодом. Использовать ларавелевский response в контроллере без оберток и велосипедов.

class OrderUpdateRequest extends FormRequest
{
    /**
     * Determine if the user is authorized to make this request.
     *
     * @return bool
     */
    public function authorize(): bool
    {
        return $this->order->canChangeStatus($this->get('status'))&&$this->order->canUpdate();
    }
}

Не надо так:

switch ($this->getMethod())
        {
            case 'PATCH':
                return [
                    'table_id' => ['numeric', 'exists:tables,id'],
                    'user_id' => ['numeric', 'exists:users,id'],
                    'status' => ['string', 'in:'. Order::NEW.','.Order::WORK.','.Order::CLOSE.','.Order::PAID],
                ];
            case 'PUT':
                return [
                    'table_id' => ['required', 'numeric', 'exists:tables,id'],
                    'user_id' => ['required', 'numeric', 'exists:users,id'],
                    'status' => ['required', 'string', 'in:'. Order::NEW.','.Order::WORK.','.Order::CLOSE.','.Order::PAID],
                ];
        }

1. Email

$firstName = fake()->firstName();
$emal = $firstName.'@mail.ru';

2. Phone

private static $phone = 0;<br>
<br>
$phone = '700000000'.str_pad((self::phone++), 2, '0');