Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Synchronous Block for VM.requires #135

Open
elliotBraem opened this issue Oct 7, 2023 · 6 comments
Open

Synchronous Block for VM.requires #135

elliotBraem opened this issue Oct 7, 2023 · 6 comments

Comments

@elliotBraem
Copy link
Contributor

Whenever I use VM.require, I need to do it with a null check:

const { Feed } = VM.require("efiz.near/widget/Module.Feed");
Feed = Feed || (() => <></>);

This is because VM.require is essentially a Social.get, and so data may be null on the first requests.
This is different than a Widget, which returns a Loading widget as data fetches.

I'm wondering if we could create a synchronous block that must complete before the rest continues; almost like getServerSideProps for Next.js. Or is there a better practice?

@elliotBraem elliotBraem changed the title VM.require is async, could we make it synchronous? Synchronous Block for VM.requires Dec 5, 2023
@evgenykuzyakov
Copy link
Contributor

The only option is to return null immediately during the rendering, effectively stopping the render cycle.

Maybe we should add build-in VM.await to do this.

@itexpert120
Copy link

After building UI libraries using VM.require. This is a must. My code gets very long because of all the null checks.

@klngrs
Copy link

klngrs commented May 2, 2024

Thinking about this more - it may be an anti-pattern to have a React component block rendering to wait on data. Usually, the pattern is:

  1. Initiate an async request for data
  2. Continue rendering and conditionally show a loading state until the data is ready
  3. useEffect rerenders the component when the data state has changed

Since VM.require is called within a Near component, would it be a better approach to have the VM simply internalize the || (() => <></>) logic? That solves the issue of it being all over consumer code, and solidifies an expectation of a returned JSX element. The VM would rerender it under the hood once it comes in from cache.

After some lengthy debugging this evening, I have that working locally, but wanted to get thoughts.

@itexpert120
Copy link

Would be nice to have the ability to set a custom fallback.

klngrs added a commit to klngrs/VM that referenced this issue May 2, 2024
@klngrs
Copy link

klngrs commented May 2, 2024

That would be cool. The only issue there is that, whatever the custom fallback component is, it would have to be repeated in each file. If you were following DRY and broke out the fallback component into a single file, you'd have the original issue when trying to async load a loading component.

Maybe the VM could provide a few options that live in the VM and aren't async loaded?

@klngrs
Copy link

klngrs commented May 2, 2024

klngrs added a commit to klngrs/VM that referenced this issue May 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants