React Compiler interferes with reactive function auto-tracking

[devuxer]

Hey @pzuraq ,

Not sure if this is a bug or just me not understanding the nuances of the libraries involved here, but I wrote a helper function to manage the opening, closing, and anchoring of a Material UI Menu, and to my surprise it didn't work.

Here is the helper function (and the call to the function):

import { reactive, signal } from "signalium":

export function createMenuState() {
    const rawAnchorEl = signal<HTMLElement | null>(null);
    const anchorEl = reactive(() => rawAnchorEl.value);
    const canShow = reactive(() => !!anchorEl());

    return { anchorEl, canShow, open, close };

    function open(value: HTMLElement) {
        rawAnchorEl.value = value;
    }

    function close() {
        rawAnchorEl.value = null;
    }
}

export const sortMenuState = createMenuState();

Here is the menu component:

import { Check as CheckIcon } from "@mui/icons-material";
import { ListItemText, Menu, MenuItem } from "@mui/material";
import { component } from "signalium/react";
import { sortMenuState as state } from "./toolbar-state";

function SortMenu() {
    return (
        <Menu
            open={state.canShow()}
            anchorEl={state.anchorEl()}
            anchorOrigin={{ vertical: "bottom", horizontal: "left" }}
            transformOrigin={{ vertical: "top", horizontal: "left" }}
            onClose={state.close}
        >
            <MenuItem onClick={state.close}>
                <CheckIcon />
                <ListItemText>Unit Name A-Z</ListItemText>
            </MenuItem>
            <MenuItem onClick={state.close}>
                <ListItemText>Unit Name Z-A</ListItemText>
            </MenuItem>
        </Menu>
    );
}

export default component(SortMenu);

Here is the button that spawns the menu:

import { FilterList as SortIcon } from "@mui/icons-material";
import { Button } from "@mui/material";
import { component } from "signalium/react";
import SortMenu from "./SortMenu";
import { sortMenuState } from "./toolbar-state";

function Toolbar() {
    return (
        <>
            <Button
                variant="text"
                startIcon={<SortIcon />}
                color="secondary"
                onClick={e => {
                    sortMenuState.open(e.currentTarget);
                }}
            >
                Sort
            </Button>
            <SortMenu />
        </>
    );
}

export default component(Toolbar);

If I look at the DOM in the dev tools, I see an expander very briefly appear for this element:

<span class="MuiTouchRipple-root css-r3djoj-MuiTouchRipple-root"></span>`

However, the menu itself never appears or appears so briefly that I cannot see it.

I added a bunch of console logs and confirmed that when I push the menu button, the value of the rawAnchorEl signal does indeed get set to the expected HTML element, and the SortMenu component does re-render. Even though the menu immediately disappears, though, rawAnchorEl never returns to null (i.e., the close mutation function never gets called).

I tried to use Anthropic Claude to debug this, and it "thought" the problem was something to do with MUI's use of React Portals:

MUI's Menu uses React portals and internal state management that might not play well with Signalium's reactive wrappers. The reactive() function might not be triggering the necessary React re-renders for the portal to mount.

If I ditch all the Signalium code and just follow MUI's example in the docs, which shows the anchor element being stored in a local useState, everything works fine.

Any insight on what could be going on here and if it's possible to fix this without reverting to useState?

[devuxer]

Interestingly, this works:

import { Check as CheckIcon, FilterList as SortIcon } from "@mui/icons-material";
import { Button, ListItemText, Menu, MenuItem } from "@mui/material";
import { component, useSignal } from "signalium/react";

function TempSortMenu() {
    const anchorEl = useSignal<HTMLElement | null>(null);
    return (
        <>
            <Button
                variant="text"
                startIcon={<SortIcon />}
                color="secondary"
                onClick={e => {
                    anchorEl.value = e.currentTarget;
                }}
            >
                Sort
            </Button>
            <Menu
                open={!!anchorEl.value}
                anchorEl={anchorEl.value}
                anchorOrigin={{ vertical: "bottom", horizontal: "left" }}
                transformOrigin={{ vertical: "top", horizontal: "left" }}
                onClose={close}
            >
                <MenuItem onClick={close}>
                    <CheckIcon />
                    <ListItemText>Unit Name A-Z</ListItemText>
                </MenuItem>
                <MenuItem onClick={close}>
                    <ListItemText>Unit Name Z-A</ListItemText>
                </MenuItem>
            </Menu>
        </>
    );

    function close() {
        anchorEl.value = null;
    }
}

export default component(TempSortMenu);

As does this:

import { Check as CheckIcon, FilterList as SortIcon } from "@mui/icons-material";
import { Button, ListItemText, Menu, MenuItem } from "@mui/material";
import { reactive } from "signalium";
import { component, useSignal } from "signalium/react";

function TempSortMenu() {
    const anchorEl = useSignal<HTMLElement | null>(null);
    const canShow = reactive(() => !!anchorEl.value);
    return (
        <>
            <Button
                variant="text"
                startIcon={<SortIcon />}
                color="secondary"
                onClick={e => {
                    open(e.currentTarget);
                }}
            >
                Sort
            </Button>
            <Menu
                open={canShow()}
                anchorEl={anchorEl.value}
                anchorOrigin={{ vertical: "bottom", horizontal: "left" }}
                transformOrigin={{ vertical: "top", horizontal: "left" }}
                onClose={close}
            >
                <MenuItem onClick={close}>
                    <CheckIcon />
                    <ListItemText>Unit Name A-Z</ListItemText>
                </MenuItem>
                <MenuItem onClick={close}>
                    <ListItemText>Unit Name Z-A</ListItemText>
                </MenuItem>
            </Menu>
        </>
    );

    function open(value: HTMLElement) {
        anchorEl.value = value;
    }

    function close() {
        anchorEl.value = null;
    }
}

export default component(TempSortMenu);

And, yes, this...

import { Check as CheckIcon, FilterList as SortIcon } from "@mui/icons-material";
import { Button, ListItemText, Menu, MenuItem } from "@mui/material";
import { reactive } from "signalium";
import { component, useSignal } from "signalium/react";

function useMenuState() {
    const rawAnchorEl = useSignal<HTMLElement | null>(null);
    const anchorEl = reactive(() => rawAnchorEl.value);
    const canShow = reactive(() => !!anchorEl());

    function open(value: HTMLElement) {
        rawAnchorEl.value = value;
    }

    function close() {
        rawAnchorEl.value = null;
    }

    return { anchorEl, canShow, open, close };
}

function TempSortMenu() {
    const { anchorEl, canShow, open, close } = useMenuState();
    return (
        <>
            <Button
                variant="text"
                startIcon={<SortIcon />}
                color="secondary"
                onClick={e => {
                    open(e.currentTarget);
                }}
            >
                Sort
            </Button>
            <Menu
                open={canShow()}
                anchorEl={anchorEl()}
                anchorOrigin={{ vertical: "bottom", horizontal: "left" }}
                transformOrigin={{ vertical: "top", horizontal: "left" }}
                onClose={close}
            >
                <MenuItem onClick={close}>
                    <CheckIcon />
                    <ListItemText>Unit Name A-Z</ListItemText>
                </MenuItem>
                <MenuItem onClick={close}>
                    <ListItemText>Unit Name Z-A</ListItemText>
                </MenuItem>
            </Menu>
        </>
    );
}

export default component(TempSortMenu);

So, it seems useState is not necessary, but keeping the state in a local hook is necessary. I do not really understand why, though.

[pzuraq]

Hmm, this is definitely interesting, I would expect that initial example to work. I could imagine it's something to do with you creating a global singleton though and maybe it's somehow getting shared between multiple instances? Can you push a git repo with a reproduction so I can take a closer look?

FWIW, if you wanted to make this the equivalent of a reusable "hook", I do think that would be better. It's still best to avoid global state when possible since it comes with a lot of these kinds of issues. I would do that like this:

import { Check as CheckIcon, FilterList as SortIcon } from "@mui/icons-material";
import { Button, ListItemText, Menu, MenuItem } from "@mui/material";
import { useState } from "react";
import { signal, reactive } from "signalium";
import { component } from "signalium/react";

const createMenuState = reactive((_id: number) => {
    const rawAnchorEl = signal<HTMLElement | null>(null);
    const anchorEl = reactive(() => rawAnchorEl.value);
    const canShow = reactive(() => !!anchorEl());

    function open(value: HTMLElement) {
        rawAnchorEl.value = value;
    }

    function close() {
        rawAnchorEl.value = null;
    }

    return { anchorEl, canShow, open, close };
});

let currentId = 0;

function TempSortMenu() {
    const [id] = useState(() => currentId++);
    const { anchorEl, canShow, open, close } = createMenuState(id);
    
    return (
        <>
            <Button
                variant="text"
                startIcon={<SortIcon />}
                color="secondary"
                onClick={e => {
                    open(e.currentTarget);
                }}
            >
                Sort
            </Button>
            <Menu
                open={canShow()}
                anchorEl={anchorEl()}
                anchorOrigin={{ vertical: "bottom", horizontal: "left" }}
                transformOrigin={{ vertical: "top", horizontal: "left" }}
                onClose={close}
            >
                <MenuItem onClick={close}>
                    <CheckIcon />
                    <ListItemText>Unit Name A-Z</ListItemText>
                </MenuItem>
                <MenuItem onClick={close}>
                    <ListItemText>Unit Name Z-A</ListItemText>
                </MenuItem>
            </Menu>
        </>
    );
}

export default component(TempSortMenu);

The reason this works is id is stable, so you always get back the same instance of your object. Reactive functions can't use useState because that would disrupt functional purity - we wouldn't be allowed to share results. But function results can be stateful, since they do not disrupt purity in the same way. It doesn't have to be id, it could be a reference to an HTML element or anything else - it just needs to be unique to this component instance.

Sometimes I find that my reactive functions do look decently similar to hooks in this way, usually when working directly with UI state. This makes sense - Hooks were never terrible for working with UI state, and it makes some amount of sense for UI state computation to be tied to rendering. Where it gets really tricky is with async state, data fetching, business logic, etc. These are things that I find work much more naturally with reactive functions. For an example (though very much WIP), see the Signalium Query package I've been working on - it feels very natural to be working with these primitives in a data layer.

[devuxer]

Hey @pzuraq , Thanks for your reply.

Edit: The new unexpected failure turned out to be a simple matter of using sort instead of toSorted, so there is just the one bug--the one involving the sort menu.

I encountered yet another unexpected failure today, this time involving a component that uses a globally-defined reactive function failing to refresh when a dependent signal of the reactive function updates. Logging the dependent signal to console solves the problem, but I'm pretty sure this shouldn't be needed.

I went ahead and created a (fairly) minimal repro that demonstrates both issues the issue with the sort menu:

https://github.com/devuxer/signalium-debug

Please let me know if this is helpful or if you need any additional information.

[devuxer]

As an experiment, I added a new "jotai" branch to the debug repo that demonstrates that the sort menu bug does not occur with equivalent Jotai code instead of Signalium.

[pzuraq]

Ah, so @devuxer you need to import the same state in both components if they're going to be sharing that state:

import SortIcon from '@mui/icons-material/FilterList';
import Button from '@mui/material/Button';
import Stack from '@mui/material/Stack';
import ToolbarCore from '@mui/material/Toolbar';
import { component } from 'signalium/react';
import BrokenSortMenu from './BrokenSortMenu';
import { brokenSortMenuState } from './toolbar-state';

function Toolbar() {
  return (
    <>
      <ToolbarCore sx={{ justifyContent: 'space-between' }}>
        <Stack direction="row" spacing={6} alignItems="center">
          <Button
            variant="text"
            startIcon={<SortIcon />}
            color="secondary"
            onClick={(e) => {
              brokenSortMenuState.open(e.currentTarget);
            }}
          >
            Sort (broken)
          </Button>
        </Stack>
      </ToolbarCore>
      <BrokenSortMenu />
    </>
  );
}

export default component(Toolbar);

This works locally for me, and it should work generally as long as you only have one instance of that component rendered at a given time

[devuxer]

@pzuraq ,

Gah, that was actually a dumb mistake on my part. I just pushed a fix to "main", which now properly demonstrates the issue.

I also encountered the Dashboard sorting bug again (I was incorrect that it was solved by using toSorted instead of sorted, though it did eliminate some of the failure scenarios). This time, I put the repro in it's own branch ("dashboard-bug").

So, you can now experience the original bug (the one that causes the sort menu not to appear) in the main branch and the new bug (the one where the sort menu works, but the dashboard does not re-sort) in the dashboard-bug branch.

My hunch is that these two issues are related. For both of these bugs, the workaround seems to be to make sure the component that is not updating properly has a nested function (like getToolbar() or getItems()). The function doesn't necessarily need to involve the signal/reactive function.

[pzuraq]

@devuxer I think this is being caused by the React compiler. The React compiler is automatically memoizing the functions, which interferes with Signalium's autotracking, because Signalium needs to track dependencies each time it runs. This combines with the double rerender that React does in dev mode to basically destroy Signalium's rerender tree.

I suspected this would be an issue with the new compiler, but half the reason I built Signalium is as a replacement for the compiler. The compiler is, in my opinion, a band-aid solution on top of the issues that Hooks have. We're encountering massive memory usage with hooks at scale in our React Native apps, primarily from dependency arrays which are being reallocated constantly.

Can you try to disable the React compiler and use traditional semantics for hooks/components?

[pzuraq]

Also, fwiw, you should do this form instead of the way you're currently doing it:

const MyComponent = component(() => {});

It's not 100% necessary, but I have added some small transforms for component() that make nicer, e.g. automatically adding callback wrappers for the functions. The transforms are necessary for async functions, but we don't support async components (yet).

[devuxer]

@devuxer I think this is being caused by the React compiler.

Ahh, that would make sense, and you kind of answered a question I've been wondering about--is the React Compiler necessary/helpful if managing most state outside of components? I have another project where I use Jotai and have almost no useState, useCallback, useMemo, etc., because all of that plumbing is handled elsewhere. Same thing with this project.

Your comment prompted me to check the docs, which reminded me of this:

The React team has been attempting to solve these issues with an experimental compiler that purports to automatically add calls to useMemo, useCallback, and React.memo, reducing the cognitive overhead that plagues hooks usages - but I don't think that this is going to work, for the simple reason that adding an additional layer of compiler magic which further obfuscates the usage of hooks seems like it ultimately will add more fuel to the raging firestorm of emergent complexity. You can't dig yourself out of a hole, so to speak.

I think, technically, it's no longer considered "experimental", but this doesn't change your point that it's a band-aid.

Also, you might want to consider adding something to the getting started page that mentions that Signalium may not work properly if React Compiler is enabled.

Can you try to disable the React compiler and use traditional semantics for hooks/components?

Yes, done, and I can confirm that both the issues I was experiencing disappeared immediately. More than happy to get rid of an unnecessary build step!

Also, fwiw, you should do this form instead of the way you're currently doing it: const MyComponent = component(() => {});

Gotcha. Easily done with this Regex (courtesy of Claude):

Find: ^function (\w+)\((.*?)\) \{([\s\S]*?)\n\}(\n+)export default component\(\1\);
Replace: const $1 = component(($2) => {$3\n});$4export default $1;

Not a major issue, but this does mean components aren't hoisted if you have multiple components defined in one file. Fortunately, I haven't found myself wanting to do this yet for this project.

[pzuraq]

Not a major issue, but this does mean components aren't hoisted if you have multiple components defined in one file. Fortunately, I haven't found myself wanting to do this yet for this project.

True! Though that only really matters if you're referencing the components directly in the module - if you're calling them lazily (e.g. within another component) they'll be defined by the time that function runs. Long term I'm really hoping function decorators make it into the language, because I do think they would be amazing for this, best of both worlds.

I'll definitely add a more prominent note about the React Compiler issues, and I'll update this ticket to track that. I'm pretty busy this week and will be going on leave for a little while, so may be a minute before I can actually update it.

[devuxer]

True! Though that only really matters if you're referencing the components directly in the module - if you're calling them lazily (e.g. within another component) they'll be defined by the time that function runs.

Ahh, you're right!

function decorators make it into the language, because I do think they would be amazing for this, best of both worlds.

That would definitely make things a little more elegant, though the component wrapper is pretty streamlined compared to using a ton of hooks, which is what I'm used to with Jotai.

I'll definitely add a more prominent note about the React Compiler issues, and I'll update this ticket to track that. I'm pretty busy this week and will be going on leave for a little while, so may be a minute before I can actually update it.

Sounds good, and thanks for being so responsive. I was lucky to catch you when I did. Enjoy your time off!

[devuxer]

Also, fwiw, you should do this form instead of the way you're currently doing it:

const MyComponent = component(() => {});
It's not 100% necessary, but I have added some small transforms for component() that make nicer, e.g. automatically adding callback wrappers for the functions. The transforms are necessary for async functions, but we don't support async components (yet).

Hey @pzuraq ,

It appears that this pattern breaks React Fast Refresh (https://github.com/vitejs/vite-plugin-react/tree/main/packages/plugin-react#consistent-components-exports).

It seems that React Fast Refresh requires that anything that wraps a React component still looks like a React component.

Happy to make this a separate issue if you agree this is a genuine problem.

EDIT:

Took some doing, but I came up with what I think is a reasonable workaround:

Instead of wrapping my components with component, I devised a function that wraps component and exposes a new component based on the original one, like so:

import { component } from "signalium/react";

export function makeReactive<TProps extends object>(fn: Parameters<typeof component<TProps>>[0]) {
    const InnerComponent = component(fn);

    function Component(props: TProps) {
        return <InnerComponent {...props} />;
    }

    return Component;
}

This seems to convince Vite/React that the component wrapper is an actual React component. I'm not sure if there are any negative ramifications of doing this, but HMR is now working great, and I haven't noticed any performance difference in production.

[pzuraq]

Sorry just noticed this comment, I've been on leave for a while now, just getting back to work.

Huh, that's really interesting. So how do you use this function? Is there something I can do to make it think that the function returned by component is a proper React component?

[devuxer]

Hey, welcome back.

Assuming you're asking about the makeReactive function, I've just been using that exactly the same way I had been using component.

Example:

import Stack from "@mui/material/Stack";
import { makeReactive } from "@/common/make-reactive";
import TableView from "@/features/dashboard/TableView";
import { dashboardFormat, unitSummaryStates } from "./dashboard-state";
import Toolbar from "./toolbar/Toolbar";
import UnitSummary from "./unit-summary/UnitSummary";

const Dashboard = makeReactive(() => {
    return (
        <Stack spacing={2} sx={{ minWidth: "35em", minHeight: "50em", p: 2 }}>
            <Toolbar />
            {getBody()}
        </Stack>
    );

    function getBody() {
        switch (dashboardFormat.value) {
            case "Card":
                return unitSummaryStates().map(x => <UnitSummary key={x.code} state={x} />);
            case "Table":
                return <TableView />;
        }
    }
});

export default Dashboard;

Is there any downside to this? If not, it's not really any difference DX-wise for me to keep using makeReactive. Or, if you think it won't break anything, perhaps you could just incorporate this function into the library somehow.

That said, it's a bit surprising I'm the only one who's hit this, making me think I might have something wrong with my setup.