Big function in parent or in children component?

[frederikhors]

I have a component parent (Team.svelte) and a component children (Player.svelte).

The question: can I create a big function like the one below in the child components or should I create it in the parent and pass down it as prop to al children?

I mean for best performances what is the correct way?

Or should I create it in a module=context of the children component (but maybe is not possible because I need some variables)?

I'm worried to create it in the children (Player.svelte) component because I'm afraid it gets created for each player at runtime instead of one time only in the parent (Team.svelte).

What is the idiomatic way in Svelte 5?

const bigFunction = createQuery(() => ({
    queryKey: [someKey],
    queryFn: someFunc,
    enabled: check,
}));

[ismaildasci]

Good question! The answer really depends on what data you need and how you want to use it.

If all players share the same query:

Put createQuery in the parent (Team.svelte) and pass the result down as a prop. This way you only make one request and all children share the same cached data. This is typically what you want for "team-level" data.

If each player needs their own query:

Put createQuery in the child (Player.svelte). Yes, it creates a query instance per player, but that is intentional - each player might need different data (e.g., queryKey: ["player", player.id]). TanStack Query handles caching smartly, so identical queries get deduplicated anyway.

Performance-wise:

Don't worry too much about function creation overhead. JavaScript engines are incredibly fast at creating functions, and Svelte 5's reactivity system is optimized for this. The real performance consideration is network requests, not function instances.

The context="module" approach:

You're right that it won't work here since you need reactive variables. Module-level code runs once at import time and can't access component state.

TL;DR: If every player needs the same data → parent. If each player needs player-specific data → child. Let the data requirements drive your architecture, not premature optimization concerns.