fkk

Если сперва запустить Amnezia VPN с раздельным тунелированием, а потом - Cisco Any Connect
То они более не конфликтуют и работают вместе (Windows).

<?php

$string = "k1/k2/k3";
$keys = explode('/', $string);

$arr = [];

$current = &$arr;
foreach ($keys as $key) {
    $current = &$current[$key];
}

$current = "last nested item";
var_dump($arr);

/*
array(1) {
  ["k1"]=>
  array(1) {
    ["k2"]=>
    array(1) {
      ["k3"]=>
      &string(16) "last nested item"
    }
  }
}
*/

Как воображение вообще дошло до '[\'' . $v . '\']'?

> Докер ужасно работает на Windows.
Нормально все работает. никакой глобально разницы не вижу.
Просто надо помнить, что если используется WSL2 - хранить файлы проекта надо так же в файловой системе WSL2, иначе будет тормознуто все.

Ну потому, что ты запускаешь композер... И все, это весь твой ENTRYPOINT, который отработав отдает код 1. Ты же не запускаешь свой условный php-fpm и правда этому удивляешься?

> что бы при старте контейнера в нем сразу загружались все перечисленные зависимости из файла composer.json

В этом не то, чтобы много смысла, Dockerfile это не про старт контейнера, а его сборку. Если тебе нужно будет обновить зависимости - ты будешь пересобирать весь образ? Это не очень логично.

Можно запустить любой готовый образ композера с командой install, чтобы у тебя приехали все зависимости.
Можно зайти в шелл запущенного контейнера php и сделать composer i.
Можно конечно написать рабочий Dockerfile, который делает RUN composer i, а в ENTRYPOINT'е имеет запуск демона php-fpm...

Внезапно исправилось тем, что просто подключил провод по более короткому Display Port (самый обычный нищий провод с коробки от моника).

Было по 3ех метровому HDMI (покупал кстати отдельно и за дорого по меркам кабеля, он вроде весь в оплетке, толстенный, металлические насадки, DEXP Premium)

Я буквально проверил так:

Вырубил холодильник с розетки, воткнул обратно - монитор погас.
Сменил кабель, сделал тоже самое - монитор не гаснет.

Никак, вообще. Сборщиков и плагинов масса, замотать фарш после сборки JSX => JS обратно... Такая себе затея. В итоге ты никак не получишь нормального кода, который хоть чуточку можно поддерживать.

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

Да, выгрузка user32.dll, но через PWSH, меня устраивает.

# Helper functions for building the class
$script:nativeMethods = @();
function Register-NativeMethod([string]$dll, [string]$methodSignature)
{
    $script:nativeMethods += [PSCustomObject]@{ Dll = $dll; Signature = $methodSignature; }
}
function Add-NativeMethods()
{
    $nativeMethodsCode = $script:nativeMethods | % { "
        [DllImport(`"$($_.Dll)`")]
        public static extern $($_.Signature);
    " }

    Add-Type @"
        using System;
        using System.Runtime.InteropServices;
        public static class NativeMethods {
            $nativeMethodsCode
        }
"@
}

Register-NativeMethod "user32.dll" "bool SetWindowText(IntPtr hWnd, string lpString)"
Add-NativeMethods

$myprocess = start-process Notepad -Passthru

# If you change the title immediately nothing will happen because the process isn't done loading.
sleep 1

[NativeMethods]::SetWindowText($myprocess.MainWindowHandle, "something")

соус

> не понимаю, почему не работает 2й.

document.querySelector('.layers__container').style.transform = `rotateX(${moveY})`
document.querySelector('.layers__container').style.transform = `rotateY(${moveX})`

Потому, что ты перетираешь значение style.transform двумя разными значениями, второе заменяет первое.

> метод Object.assign инлайново прописал для documentElement АТРИБУТ style.
Не совсем, он буквально сделал:

document.documentElement.style.prop1 = "value1";
document.documentElement.style.prop2 = "value2";

Сам он ничего не прописывал, это уже логика работы DOM ноды и ее API.
Просто прочти документацию к Object.assign, лучше в отрыве от DOM API, ибо у DOM API и его объектов есть свои магические методы, геттеры, сеттеры и прочее:



> console.log(Object.entries(document.documentElement)) то выведутся все пары ключ+значение

У "простых" объектов - да, но все сложнее. Если посмотреть MDN описание для Object.entries, то можно увидеть, что он отдает только перечисляемые свойства: An array of strings representing the given object's own enumerable string-keyed property keys.

1. Где декларация функции shuffle?
2. Чего вы ожидали от вызова shuffle(questionsDat);?

Даже если допустить, что функция у вас где-то есть, то что этот вызов должен сделать? В теории функция shuffle может напрямую изменить входящий массив, но обычно так никто не делает, обычно все идут по пути иммутабельности. Т.е. вам нужно использовать то, что возвращает shuffle.

Если хотите мутировать исходный массив, можно взять Array.sort и Math.random.

questionsDat.sort(() => .5 - Math.random())

Причем тут VDS, зачем вам вообще нода? Чистый Vue это больше о SPA. Вы о SPA или SSR/G?

Если вы хотите классический SPA, то вам (не) нужна нода, она нужна для сборки и локальной разработки, но на выходе у вас статика (html, js, css и еще какой-то набор ассетов аля картинки, шрифты и так далее).

Что там делает API и как он живет - фронту не важно и его не касается, ему не важно какой там стек, фронту важно одно - адрес, где бекенд живет и чтобы бекенд отдавал ответы на запросы в нужном фронту формате.

Поэтому что вам конфигурировать? Что вы хотите?
Ну в общих чертах вам нужен:

nginx, который:
- Отдает статику на 80/443 с вашим index.html и набором ассетов.
- Дает доступ к API проксипасом на условный путь /api юзая php-fpm линком с другого контейнера.

Как вы это упакуете на уровне докера - хз, делайте как удобно. Только понимайте, что фронт для локальной разработки нужно запускать в dev режиме, через nodejs, (HMR там и все такое) а для пре\прода - собирать в статику.

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

Да и как вы хотите хранить проекты? Монореп или все таки разные репы? Если разные - можете вообще сделать для каждого проекта сборку в docker имаджы и сторить их где-то в Gitlab Registry или аналогах с независимым деплоем фронта и бека. кароче вариантов масса. Выбирайте по возможностям и средствам. Возможно вам проще нанять прошаренного девопса.

В общем виде, я бы делал как-то так:

const LIMIT = 10;

const getProducts = async (offset, limit) => { ... }

function App () {
  const [offset, setOffset] = useState(0);
  const [products, setProducts] = useState([])

  useEffect(() => {
    getProducts(offset, LIMIT).then(products => setProducts(v => [...v, ...products]))
  }, [offset]);

  return <RenderProducts onScroll={() => { // increment offset }} />
}

Конечно, ваш бекенд должен уметь отдавать данные по limit & offset.
И лучше вынести всю работу с данными в стор, тогда не нужен будет уродливый useEffect.

Что-то вроде (nanostores):

// store.ts
const LIMIT = 30;

export const $products = map({
  offset: 0,
  products: [],
  isLoading: true
})

onMount($products, () => {
  fetchProducts()
})

const fetchProducts = action($products, "fetchProducts", async store => {
  const { products, offset } = store.get();

  // TODO: add error handling
  store.setKey("isLoading", true);
  const newPartOfProducts = await api.getProducts(offset, LIMIT);
  store.setKey("products", [...products, ...newPartOfProducts ]);
  store.setKey("isLoading", false);
});

const incrementOffset = action($products, "incrementOffset", store => {
  const { offset } = store.get();
  store.setKey("offset", offset + LIMIT);
  fetchProducts()
})

export const $productsMutations = { incrementOffset }

// App.tsx

function App () {
  const { isLoading, products } = useStore($products)

  return (
    <Fragment>
      <RenderProducts onScroll={$productsMutations.incrementOffset} products={products} />
      {isLoading && <LoadingIndicator />}
    </Fragment>
  )
}