You Might Not Need an Effect

Overview¶

Most Effects are unnecessary. If your logic only adjusts one thing based on another thing you already have, it belongs in the render — not in an Effect. This page walks through the common cases where an Effect looks right and isn't, with the render counts each one costs.

How to remove unnecessary Effects¶

Work through each Effect in your code and ask: does this code need to run after a render, or could it run while rendering?

An Effect is genuinely necessary when the component must reach something outside ReactPy — subscribing to a queue, opening a socket, starting a task. Everything below is the opposite case: the "external system" is a value your component already has.

If you're not sure what Effects are for in the first place, start with Synchronizing with Effects.

Updating state based on props or state¶

A component shows a name built from two fields. The tempting version stores the combination and keeps it in step with an Effect:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

@component
def form():
    first_name, set_first_name = use_state("Ada")
    last_name, set_last_name = use_state("Lovelace")
    # Wrong: this value is not state, it is a calculation of other state.
    full_name, set_full_name = use_state("")

    def effect():
        set_full_name(f"{first_name} {last_name}")

    use_effect(effect, dependencies=[first_name, last_name])

    return html.div(
        html.h1(full_name or "(nothing yet)"),
        html.input(
            {
                "value": first_name,
                "onChange": lambda event: set_first_name(event["target"]["value"]),
            }
        ),
        html.input(
            {
                "value": last_name,
                "onChange": lambda event: set_last_name(event["target"]["value"]),
            }
        ),
    )

1

# TODO

Remove the state variable and the Effect, and calculate it during render:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

@component
def form():
    first_name, set_first_name = use_state("Ada")
    last_name, set_last_name = use_state("Lovelace")
    # Right: calculated during rendering, so it is always in sync.
    full_name = f"{first_name} {last_name}"

    return html.div(
        html.h1(full_name),
        html.input(
            {
                "value": first_name,
                "onChange": lambda event: set_first_name(event["target"]["value"]),
            }
        ),
        html.input(
            {
                "value": last_name,
                "onChange": lambda event: set_last_name(event["target"]["value"]),
            }
        ),
    )

1

# TODO

The difference is measurable, and the first row of each is the part users actually see:

Verified in a Layout. The Effect version renders once with an empty name, sets state from the Effect, renders again — every keystroke costs two renders instead of one, and the very first paint is wrong. Nothing downstream can rescue that first frame, because it is a real render that a real client receives.

When something can be calculated from existing props or state, don't put it in state. Calculate it during render. Fewer state variables means less code, no way for two of them to drift apart, and half the renders. If this feels unfamiliar, Thinking in React covers what belongs in state.

Caching expensive calculations¶

When a calculation genuinely is expensive, the answer is still not state plus an Effect — it is use_memo, which caches a value without adding a render:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

@component
def todo_list():
    filter_name, set_filter_name = use_state("all")
    new_todo, set_new_todo = use_state("")

    def visible_todos():
        # A real filter over a real dataset. It records every run so the
        # effect of use_memo is countable.
        filter_runs.append(filter_name)
        if filter_name == "all":
            return todos
        if filter_name == "active":
            return [todo for todo in todos if not todo["completed"]]
        return [todo for todo in todos if todo["completed"]]

    shown = use_memo(visible_todos)

    return html.div(
        html.p(f"{len(shown)} of {len(todos)} shown (filter: {filter_name})"),
        html.ul([html.li({"key": todo["id"]}, todo["text"]) for todo in shown]),
        html.button(
            {
                "onClick": lambda event: set_filter_name(
                    {"all": "active", "active": "completed", "completed": "all"}[
                        filter_name
                    ]
                )
            },
            "Change filter",
        ),
        html.input(
            {
                "placeholder": "new todo",
                "value": new_todo,
                "onChange": lambda event: set_new_todo(event["target"]["value"]),
            }
        ),
    )

1

# TODO

The filter records each run so the result is countable. Verified: after two keystrokes the component has rendered three times and the filter has run once; pressing Change filter adds a render and a second run. The value is recomputed exactly when the inputs it reads change, and never on a render that didn't change them.

Two properties worth knowing, both verified:

• use_memo infers its dependencies the same way use_effect does — from the names the function reads. Pass dependencies=[] to pin a value forever, or dependencies=None to recompute on every render. See Use Memo.
• It caches the value, not the render. The component body still runs on every render; ReactPy has no component-level memo, so a child re-runs whenever its parent does. use_memo saves the computation, never the render — see Render and Commit.

Mutating a value in place and "setting" it back defeats use_memo too, for the same reason it defeats use_state: the new value compares equal to the old one. Build a new object instead (Updating Arrays in State).

Resetting all state when a prop changes¶

A profile page holds a comment draft. When the user navigates to a different profile, the draft should not follow them:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

@component
def profile(user_id):
    # Any state declared here is thrown away whenever the key changes, along
    # with the state of every component below it. No Effect needed.
    comment, set_comment = use_state("")

    return html.div(
        html.h2(f"profile {user_id}"),
        html.textarea(
            {
                "value": comment,
                "placeholder": "leave a comment",
                "onChange": lambda event: set_comment(event["target"]["value"]),
            }
        ),
        html.p(f"draft: {comment or '(empty)'}"),
    )


@component
def profile_page():
    user_id, set_user_id = use_state("ada")

    return html.div(
        html.button(
            {
                "onClick": lambda event: set_user_id(
                    "grace" if user_id == "ada" else "ada"
                )
            },
            "Next profile",
        ),
        # The key is what makes ReactPy treat this as a different profile.
        profile(user_id, key=user_id),
    )

1

# TODO

Verified: type a draft, press Next profile, and the draft is empty on the new profile — in a single extra render.

Passing key=user_id tells ReactPy that a different user_id means a different component instance. It tears down profile() and everything below it and builds them again, so all of their state starts fresh. One line, and it covers every piece of state in the whole subtree — no Effect, and no remembering to add one to each nested component.

The Effect version (set_comment("") in an Effect depending on user_id) is worse in three ways: the subtree renders once with the previous user's draft still in it, every nested component needs its own copy, and a piece of state added later silently fails to reset. See Preserving and Resetting State for the full mechanism.

Adjusting some state when a prop changes¶

Sometimes you don't want to throw state away — just invalidate part of it when an input changes. A list keeps a selection, and a new items prop should clear it. React's advice is to call the setter during render, and that escape hatch does not work in ReactPy. Measured, the render-phase-setter version takes four renders and the client receives this sequence:

<root>                     items: [a,b,c]     selected: None
/children/0/children/1     items: [a,b,c]     selected: a
<root>                     items: [a,b,c,i4]  selected: a     <-- stale, and delivered
/children/0/children/1     items: [a,b,c,i4]  selected: None

React throws the discarded render away; ReactPy hands the model to the socket as soon as it exists, so the stale frame ships. Use a derived read instead. Store the value alongside what it belonged to, and let the read decide whether it is still valid:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

@component
def list_box(items):
    is_reverse, set_is_reverse = use_state(False)
    # One state value that remembers which list the choice belonged to. The
    # selection is *derived*: if the items changed, the old choice is not
    # valid for the new list, so it reads back as None. No Effect, no
    # intermediate render with a stale selection.
    chosen, set_chosen = use_state({"items": None, "value": None})
    selection = chosen["value"] if chosen["items"] == items else None

    shown = items[::-1] if is_reverse else items

    return html.div(
        html.p(f"items: {shown}  selected: {selection}"),
        html.button(
            {"onClick": lambda event: set_is_reverse(not is_reverse)}, "Reverse"
        ),
        html.button(
            {"onClick": lambda event: set_chosen({"items": items, "value": shown[0]})},
            "Select",
        ),
    )


@component
def app():
    items, set_items = use_state(["a", "b", "c"])

    return html.div(
        html.button(
            {"onClick": lambda event: set_items([*items, f"item {len(items) + 1}"])},
            "Add item",
        ),
        list_box(items),
    )

1

# TODO

Verified: Select costs one render and shows the selection; Add item costs one render and the selection is already gone in that same patch — three renders total, no stale frame.

The general shape is a guard on the read rather than a call to the setter:

is_valid = chosen["items"] == items
selection = chosen["value"] if is_valid else None

Sharing logic between event handlers¶

Two handlers should do the same thing on input. There is no reason for this to involve an Effect:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

@component
def shipping_form():
    shipping_city, set_shipping_city = use_state("")
    billing_city, set_billing_city = use_state("")

    def handle_shipping_change(event):
        city = event["target"]["value"]
        set_shipping_city(city)
        # Shared logic: just call the other setter. Handlers are ordinary
        # functions; there is nothing to schedule and nothing to re-sync.
        set_billing_city(city)

    return html.div(
        html.p(f"shipping: {shipping_city or '(empty)'}"),
        html.p(f"billing:  {billing_city or '(empty)'}"),
        html.input(
            {"value": shipping_city, "onChange": handle_shipping_change},
        ),
        html.input(
            {
                "value": billing_city,
                "onChange": lambda event: set_billing_city(event["target"]["value"]),
            }
        ),
    )

1

# TODO

Verified: type in the shipping field and the billing readout changes with it, in one render, because both setters were called from one handler.

Event handlers are ordinary functions. Call one from the other, extract the shared part into a plain function, or pass the other setter as a parameter. Whatever React's docs tell you here transfers unchanged, because none of it is rendering work.

Sending a POST request¶

Submitting a form is an event, not a consequence of rendering. Do the work in the handler:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

@component
def signup():
    email, set_email = use_state("")
    status, set_status = use_state("idle")

    async def handle_submit(event):
        event.preventDefault()
        # Wrong: set a "pending" flag and let an Effect notice it. That costs
        # a state variable, a render, and a way to submit the same value twice.
        #     set_pending(True)
        #
        # Right: do the work from the handler. It runs once per submission.
        set_status("sending...")
        await send_email(email)
        set_status(f"sent to {email}")

    return html.div(
        html.p(status),
        html.form(
            {"onSubmit": handle_submit},
            html.input(
                {
                    "value": email,
                    "placeholder": "you@example.com",
                    "onChange": lambda event: set_email(event["target"]["value"]),
                }
            ),
            html.button({"type": "submit"}, "Sign up"),
        ),
    )

1

# TODO

Verified: fill the field, submit, and the transport recorded exactly one send — ['ada@example.com'].

The version to avoid is a flag plus an Effect: set_pending(True), and an Effect that watches pending. It costs a state variable, an extra render per submission, and — because Effects re-run on dependency changes and remounts — a way to send twice. event.preventDefault() stops the page navigating, and must appear literally in the handler's body, since ReactPy detects it by bytecode inspection (Creating VDOM Event Handlers).

Notifying parent components about state changes¶

A child should tell its parent something happened. Pass a callback and call it from the child's event handler — this works exactly as it does in React:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

@component
def search_box(on_search):
    query, set_query = use_state("")

    def handle_submit(event):
        event.preventDefault()
        # Not an Effect: the search happens because the user submitted.
        on_search(query)

    return html.form(
        {"onSubmit": handle_submit},
        html.input(
            {
                "value": query,
                "placeholder": "search",
                "onChange": lambda event: set_query(event["target"]["value"]),
            }
        ),
        html.button({"type": "submit"}, "Search"),
    )


@component
def app():
    results, set_results = use_state("Type something and submit.")

    def handle_search(query):
        set_results(f"searching for {query!r}..." if query else "empty query")

    return html.div(html.p(results), search_box(handle_search))

1

# TODO

Verified: type ada, submit, and the parent's paragraph reads searching for 'ada'....

What you must not do is call the parent's function from an Effect that watches a value. Handlers run once per user action; Effects run once per dependency change, which includes renders the user never caused. There is also no use_imperative_handle for the reverse direction — pass data down as props and callbacks up as arguments (Sharing State Between Components).

Chains of computations¶

When several values feed each other, keep the whole chain in render. Each intermediate is a local variable, not a state variable:

@component
def report(rows, currency):
    priced = [(*row, row[1] * RATES[currency]) for row in rows]
    total = sum(item[-1] for item in priced)
    heading = f"{currency.upper()}: {total:,.2f}"
    return html.div(html.h1(heading))

An Effect at any link in that chain means every upstream change costs an extra full render — and, as above, each of those renders is visible to the client. If one link is genuinely expensive, wrap that one in use_memo rather than putting the whole chain in state.

Initializing the application¶

Code that should run once per process does not belong in a component at all — a component's Effect runs once per connection, and a server serves many connections:

# module level, or the ASGI app's startup: runs once
configure_logging()
POOL = create_pool()

Keep a dependencies=[] Effect for work that is genuinely per-connection, such as a subscription or a session-scoped task. Never guard a process-level side effect with my_component.started = True: the function object is module-scope, so the first visitor flips the flag for everyone (VDOM Mutations).

Subscribing to an external store¶

Here is the case where the Effect is correct. The value does not live in ReactPy at all, so there is nothing to derive it from — ReactPy has to be told when it changes:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

@component
def clock_view():
    # The value is owned by `clock`, not by this component, so it cannot be
    # derived during render -- ReactPy has to be told when it changes.
    ticks, set_ticks = use_state(clock.get())

    def effect():
        # Subscribe, and hand back the unsubscribe. This is what an Effect
        # is for: the source of truth lives outside ReactPy.
        def on_change():
            set_ticks(clock.get())

        return clock.subscribe(on_change)

    use_effect(effect, dependencies=[])

    return html.div(html.h1(f"{ticks} ticks"))


@component
def app():
    watching, set_watching = use_state(True)

    return html.div(
        html.button({"onClick": lambda event: clock.tick()}, "Tick"),
        html.button(
            {"onClick": lambda event: set_watching(not watching)},
            "Stop watching" if watching else "Watch",
        ),
        *([] if not watching else [clock_view()]),
    )

1

# TODO

Verified: pressing Tick once shows 1 ticks; pressing Stop watching unmounts the view and leaves 0 listeners registered on the store.

Three things make this one legitimate where the others were not:

1. The source of truth is outside ReactPy. Deriving would mean reading clock.get() during render, which has no way to know when to run again.
2. The subscription needs a lifetime, and the clean-up is what returns the store to zero listeners.
3. The state exists to trigger a render — that is its whole purpose.

This is also where use_async_effect earns its place, when the external system is an async stream rather than a callback. See Synchronizing with Effects for cancellation and the four-way dependency table.

Fetching data, without the extra Effects¶

Fetching genuinely needs an Effect — the network is external. Everything you would otherwise stack on top of it does not. Store the response, and shape it in render:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

@component
def report_view(name):
    # Store the response *with the name it belongs to*, so a render for a new
    # report cannot display the old one's rows. The empty read is the
    # "loading" state -- derived, not a second state variable.
    loaded, set_loaded = use_state({"name": None, "data": {}})

    async def load():
        data = await catalog.fetch(name)
        set_loaded({"name": name, "data": data})

    use_async_effect(load, dependencies=[name])

    raw = loaded["data"] if loaded["name"] == name else {}

    if not raw:
        return html.p("loading...")

    # Right: the shape the page needs is computed here, from the data that
    # arrived. There is no second state variable to keep in step, so there is
    # nothing for an Effect to synchronise.
    rows = [{"label": key.title(), "value": value} for key, value in raw.items()]
    total = sum(row["value"] for row in rows)
    lines = [
        html.li({"key": row["label"]}, f"{row['label']}: {row['value']}")
        for row in rows
    ]

    return html.div(
        html.h2(f"{name}: {total} total"),
        html.ul(lines),
    )


@component
def app():
    name, set_name = use_state("orders")

    return html.div(
        html.button(
            {
                "onClick": lambda event: set_name(
                    "users" if name == "orders" else "orders"
                )
            },
            "Toggle report",
        ),
        # No `key` here on purpose: the derived read in report_view is what
        # keeps the old report off the screen, so nothing has to be remounted.
        report_view(name),
    )

1

# TODO

Verified: the Effect stores the raw response; the labels, the per-row formatting, and the total are computed during render. One request per report name (['orders', 'users']), and no rows or total state variables that could fall out of step with the response.

The example carries one more lesson in its state shape. It stores the response together with the name that produced it and derives the read:

raw = loaded["data"] if loaded["name"] == name else {}

Storing the response alone looks fine and is wrong: switch from orders to users and the component re-renders immediately, before the new response arrives, so the client receives users: 55 total above the orders rows — 55 being orders' total. Measured, and the derived read above is what fixes it, without remounting the component.

The anti-pattern is a second Effect that watches the response and sets three more state variables from it. Each of those is a value you can calculate, and each adds a render in which the page is half-updated.

Because ReactPy already runs on the server, there is usually a better option than fetching in the child at all: fetch in a parent during render, or at startup, and pass the result down as a prop. Then the child has no Effect and no loading state, and the response is shared rather than re-requested. Keep the Effect for data that depends on something only the connection knows, like use_location.

How to tell whether an Effect is necessary¶

If you cannot name what the Effect is synchronizing with, it is probably doing a render's job.

Recap¶

• An Effect runs after a render. If the work could happen during the render, it should.
• Values calculated from props or state are not state. Compute them; do not store and re-sync them. Measured: the Effect version costs twice the renders and ships a wrong first frame.
• use_memo caches expensive calculations without adding a render — but it caches values, not component renders.
• Reset state with a key, not with an Effect.
• ReactPy cannot use React's render-phase setter trick: the stale patch reaches the client. Derive the value instead.
• Sharing logic between handlers, notifying a parent, and submitting a form are all handler work.
• Subscriptions and async streams are the real use for Effects — with a clean-up, always.

Related¶

• Synchronizing with Effects — how Effects work, and their four-way dependency table
• Choosing the State Structure — avoid redundant state in the first place
• Preserving and Resetting State — resetting with key
• Use Memo and Use Callback
• Separating Events from Effects — the remaining case where reading fresh state matters