Split hooks into smaller chunks

[soord]

Currently the useDevice hook is a bit of a god object. There are many opportunities to split this out into multiple smaller hooks and use each one for more connection efficiency, decoupling, and general best practices

[rinchen]

useDevice and useMeshCore both. useMeshCore was created using useDevice as the prototype and as we expanded we occasionally added features to both. They should not really have any overlapping code, just logic differences between using a MT device and MC device

[rinchen]

The way I would prefer this to be implemented is more SOA-style (Service Oriented Architecture). These two hooks started out as device hooks.

I think we would want:

A device context. Something simple like

// DeviceContext.tsx
import { createContext, useContext } from 'react';
import type { MeshDevice } from '@meshtastic/core';

interface DeviceContextState {
  device: MeshDevice | null;
  status: 'disconnected' | 'connecting' | 'connected' | 'configured' | 'stale';
  myNodeNum: number;
  connectionType: ConnectionType | null;
}

export const DeviceContext = createContext<DeviceContextState | null>(null);

export function useDeviceCore() {
  const context = useContext(DeviceContext);
  if (!context) throw new Error('Must be used within DeviceProvider');
  return context;
}

Once the context is established, split the useDevice file into logical domains. Each hook will grab the device from context and subscribe only to the events it cares about.

A. useDeviceConnection (The Transport Layer)
Responsibility: Establishing the BLE/Serial/HTTP connection, managing the watchdog (startWatchdog, stopWatchdog), reconnect logic, and updating the base DeviceContext.

Listens to: onDeviceStatus, onMyNodeInfo, onDeviceMetadataPacket.

B. useDeviceNetwork (Nodes & Topology)
Responsibility: Maintaining the nodesMap, tracking last heard times, roles, hardware models, and processing neighbor info.

Listens to: onUserPacket, onNodeInfoPacket, onNeighborInfoPacket, onPositionPacket (strictly for coordinate updates to the node map).

State: nodes, neighborInfo, deviceOwner.

C. useDeviceMessages (Chat & Text)
Responsibility: Chat history, deduplication (seenPacketIds), optimistic UI updates for sending, and reply/emoji enrichment.

Listens to: onMeshPacket (specifically filtering for Portnums.PortNum.TEXT_MESSAGE_APP).

State: messages.

D. useDeviceMQTT (The Gateway Bridge)
Responsibility: Connecting to the Electron MQTT backend, managing the virtual node ID, sending presence intervals, and merging MQTT updates into the shared node/message stores.

Listens to: Electron MQTT IPC events (onStatus, onNodeUpdate, onMessage).

E. useDeviceTelemetry (Sensors & Health)
Responsibility: Device metrics (battery, voltage), environmental metrics (BME280/680 data), and local RF stats (channel utilization).

Listens to: onTelemetryPacket.

State: telemetry, environmentTelemetry, signalTelemetry.

F. useDeviceRouting (Mesh Mechanics)
Responsibility: Trace routes, waypoints, queue status, and raw packet logging.

Listens to: onTraceRoutePacket, onMeshPacket (for TRACEROUTE_APP and SNR/RSSI data), onWaypointPacket, onQueueStatus.

State: traceRouteResults, waypoints, rawPackets, queueStatus.

G. useDevicePlugins (Specialized Ports)
Responsibility: Grouping all the niche module packets together so they don't bloat the main application render cycle.

Listens to: onAudioPacket, onRemoteHardwarePacket, onDetectionSensorPacket, onStoreForwardPacket, onPaxcounterPacket, onZpsPacket, etc.

State: A combined reducer or individual state maps for the niche plugins.

So Telemetry might be something like

// hooks/useDeviceTelemetry.ts
import { useState, useEffect } from 'react';
import { useDeviceCore } from './DeviceContext';
import type { TelemetryPoint, EnvironmentTelemetryPoint } from '../lib/types';

export function useDeviceTelemetry() {
  const { device, status } = useDeviceCore();
  const [telemetry, setTelemetry] = useState<TelemetryPoint[]>([]);
  const [envTelemetry, setEnvTelemetry] = useState<EnvironmentTelemetryPoint[]>([]);

  useEffect(() => {
    if (!device || status !== 'configured') return;

    const unsub = device.events.onTelemetryPacket.subscribe((packet) => {
      // Logic for parsing telemetry...
      const tel = packet.data;
      
      if (tel.variant?.case === 'environmentMetrics') {
         // Update envTelemetry state
      } else if (tel.deviceMetrics) {
         // Update device telemetry state
      }
    });

    return () => unsub();
  }, [device, status]);

  return { telemetry, envTelemetry };
}

And finally, we need to address hydration from the database. Right now, useDevice fetches historical nodes and messages directly on mount via window.electronAPI.db.

When splitting this out, we should probably move the database initialization into a separate sync layer or directly into the useDeviceMessages and useDeviceNetwork hooks so that the data loading is co-located with the state it populates.

[soord]

I like the domain model, and that is basically what im doing, but I would say we should use a store instead of state in the hook. I think the hook should "try" to be pure. We can use a subscription but i wouldnt use a useEffect inside a hook probably. Other than that I think we are fairly aligned on the overarching domain driven design. I kind of did it as "drivers" for now. Feel free to take a look at the branch for the "base"

[rinchen]

The Zustland store is good with me

[rinchen]

PLAN.md I asked OpenCode how it thinks we should proceed and this was the reply. May be suboptimal.