yatay olarak ortalamak istersen, kapsayıcının belli bir genişliği olmalı. Diyelim ki var, o zaman şu değerleri verirsen

button {
    left: 50%;
    transform: translateX(-50%);
}

butonun içindeki genişliği bilmene gerek kalmaz dinamik olarak yatayda ortalayabilirsin. Dikeyde de ortalamak istersen

button {
    top: 50%;
    transform: translateY(-50%);
}

her iki eksen için istersen

button {
    top: 50%;
    left: 50%;
    transform: translate(-50%, -50%)
}

örnek bir kullanım

<div>
  <button>test</button>
</div>
<style>
div {
  width: 100%;
  height: 200px;
  border: 1px solid #ccc;
  position: relative;
}

button {
  position: absolute;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%)
}
</style>

burada önemli olan dediğim gibi buton position uygulanınca kapsayıcıda belli bir yükseklik ve genişlik yoksa sorun yaratır min. bir değer vermen gerekir ki ona göre ortalama işlemi yapabil.

aslında bu normal bir davranış, overflow: hidden ya da auto dendiğinde otomatik olarak gizleniyor içindeki elemanlar.
bu gibi durumlar için tooltip bunun içinde değilde bağımsız olarak body'nin içinde yer alan bir alanda olmalı.
fare ile ilgili elemana gelince farenin konumu (top, left) alınıp body'deki tooltip'e anlık olarak atanmalı.
ayrıca yine fare üstündeyken global bir değişkene tooltip'te görünecek değerler belirlenmeli, fare odağını çekince bu işlemleri sıfırlamalısın.
kodlar temiz olsa bir örnek verecektim ama belki bu teorik detay bir şeyleri farklı düşünmeni sağlayabilir.

ben şu şekilde kullanıyorum. genel kullandığmı componentler için

./src/components
./src/components/shared

servisler, store ve utils için

./src/services
./src/stores
./src/utils

sayfalar içinde genel view klasörünü kullanıyorum. Ama her sayfa için bir index.js oluşturuyorum çağırması daha kolay olsun diye. Ayrıca sayfaya özel componentler varsa yine ilgili klasörde belirtiyorum.

./views
./views/home
    ./views/home/index.js
    ./views/home/components

bu tamamen kişisel tercih, ben bu şekilde kullanıyorum ama seninki de fena değil, farklı bir çok alternatifini de görebilirsin. Mümkün olduğunca requestleri tek bir yerden yönetirsin. Requestlerin tamamını service klasöründe mantıklı şekillerde export edip kullanırsın. Ayrıca store yönetimi için redux toolkit çok daha kolay bir düzen kurmanı sağlar.

yapacağın şey $elemanlar değişkeninde sanırım db'den kategorileri çekiyorsun, join ile urunler tablona bağlanacaksın, böylece sadece ürün olan kategorileri döndürecek join eşleşmesinden dolayı, fonksiyonda bir şey yapmaya gerek yok.

şöyle bir sorgu olabilir

select kategoriler.* from kategoriler
inner join urunler on urunler.kat_id = kategoriler.id

yani şöyle düşün, fonksiyonda parametre olarak geçtiğin elemanı değiştirmek istiyorsan ama onu geriye döndürmek yerine değerinin direk etkilenmesini istiyorsan kullanabilirsin, sonuçta fonksiyonun sadece onunla ilgili bir işlemi olmayabilir, ya da aldığın parametreye göre fonksiyon farklı bir işlem için değer döndürebilir ama alınan parametreninde bundan etkilenilmesi istenebilir.

kısaca referans aldığın değişkenin değerini etkiliyor bu şekilde kullanırsan, en basit örneği;

<?php

$text = 'hello';
function changeText(&$text) {
    $text .= ' world';
}
changeText($text);

echo $text; // hello world

başka bir örnek

<?php

$numbers = [2, 3, 5];
function multiply(&$nums) {
    $nums = array_reduce($nums, function($prev, $num) {
        $prev[] = $num * 2;
        return $prev;
    }, []);
}
multiply($numbers);

print_r($numbers);
/*
Array
(
    [0] => 4
    [1] => 6
    [2] => 10
)
 */

tabi bu olay sadece parametre geçmekle alakalı değil, örneğin şöyle kullanımlarıda var;

$text1 = 'hello';
$text2 = &$text1;

$text2 = 'deneme';
echo $text1;

$text2 oluşturulurken $text1 referansıyla oluşturuluyor, dolayısı ile $text2 değiştirince aslında referansı yani $text1 değişiyor. Bu tarz kullanımlara çok takılma, vakti gelirse zaten ihtiyacın olduğu bir noktada mutlaka kullanırsın :)