Why component function has type Effect (ReactComponent props) but not ReactComponent props

[srghma]

e.g. consider writing page for next.js

the page function should have type {} -> JSX or ReactComponent {}

---

Actual:

mkCounter :: Effect (ReactComponent {})
mkCounter = do
  component "Counter" \props -> React.do
    counter /\ setCounter <- useState 0
    pure
      $ fragment
          [ R.button
              { onClick: handler_ $ setCounter (_ + 1)
              , children: [ R.text $ "Increment: " <> show counter ]
              }
          ]

mkPage :: Effect (ReactComponent {})
mkPage = do
  counter <- mkCounter

  component "Page" \props -> React.do
    pure
      $ fragment
          [ counter
          , counter
          ]

page :: ReactComponent {}
page = unsafePerformEffect mkPage

Expected:

counter :: ReactComponent {}
counter = component "Counter" \props -> React.do
  counter /\ setCounter <- useState 0
  pure
    $ fragment
        [ R.button
            { onClick: handler_ $ setCounter (_ + 1)
            , children: [ R.text $ "Increment: " <> show counter ]
            }
        ]

page :: ReactComponent {}
page = component "Page" \props -> React.do
  pure
    $ fragment
        [ counter
        , counter
        ]

---

Do we really need to call mkCounter()?

For example, I don't see that example from https://reactjs.org/docs/hooks-overview.html

import React, { useState } from 'react';

function Example() {
  // Declare a new state variable, which we'll call "count"
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>
        Click me
      </button>
    </div>
  );
}

was written as

import React, { useState } from 'react';

function mkExample() {
  return function Example() {
    // Declare a new state variable, which we'll call "count"
    const [count, setCount] = useState(0);

    return (
      <div>
        <p>You clicked {count} times</p>
        <button onClick={() => setCount(count + 1)}>
          Click me
        </button>
      </div>
    );
  }
}

[srghma]

What it would give - easier to use api

[starper]

@srghma To answer your question we can look into source code, where we will find out that the only reason component function is effectful is unsafeSetDisplayName function.

Personally, I don't see anything about unsafeSetDisplayName's implementation that suggests that it should be effectful. It takes a foreign type ReactComponent props (which is just a JS function), updates and then returns it, that's it.

So I agree with you, component function should not be effectful, it complicates API for no particular reason.

[srghma]

Good that we are on the same page

I would even make unsafeSetDisplayName to have type unsafeSetDisplayName :: (props -> JSX) -> ReactComponent props

[megamaddu]

It's effectful because React uses function instances as component identity. This is why React generally recommends module-level component definition. Creating component functions during render results in forced unmouting and remounting of the entire tree below that component (dumping all component and DOM state), even if all the rendered VDOM is the same as the last render and matches the real DOM. You can actually see this in JS pretty easily with HOC APIs, where withRouter(MyPage) creates a new component and is always done at the module-level as a result. This conflicts with PureScript's concepts of equality, i.e. Just 5 == Just 5 is true, even though unsafeRefEq (Just 5) (Just 5) returns false.

Using Effect captures this instance-based side effect so it can be reasoned about in PS. If you write a component "factory" function, it captures the idea that each call produces an entirely different component, regardless of behavior or display name.

You can still choose to hide this detail under the rug using unsafePerformEffect around your component definition (ex below), but it's up to you now instead of being hidden in the library because it was too easy to run into this identity issue. Even adding a typeclass constraint to a component definition! Every instance of the glass gets a separate component. This happens in every PS React wrapper I've seen btw, it's just an uncommon use case for small examples. I intend to back port this change into the regular react-basic API as well, btw (whether it's by adopting this hooks API as the primary one or some other refactor, I'm aren't sure yet)

Your initial "actual" example is a great way to write it -- keeping the PS bits effectful and running unsafePerformEffect once at the top level where next.js can pick it up. A component library could similarly expose both the effectful version (which might support a generic type constrained with type classes) alongside a fully applied version which chooses a type for some common use case.

Btw, this is explained briefly in the docs, but if that was confusing or not enough info let me know.

[starper]

@spicydonuts OK, it makes sense. I got so used to the idea that React is not PureScript-friendly and that this define component as a module-level function convention is just a necessary evil, that I completely missed the fact that this weird behavior can be captured by Effect monad.
Function which behavior changes based on the context in which it was defined should indeed be effectful.

[srghma]

It does make sense