Perpetually loading landing page of metaplex storefront

[soulsayer9029]

The Problem Metaplex web application(storefront) is not working and as the landing page loads in perpetuity

To Reproduce Steps to reproduce the behavior:

1. Clone the metaplex repository
2. cd to metaplex/js
3. yarn install
4. yarn bootstrap
5. yarn start
6. Go to localhost:3000 and see the output

The loading sign is just not going away and the page loads perpetually

Expected behavior There should not be a perpetual loading sign

Screenshots

Desktop:

• OS: Ubuntu 18
• Browser Mozilla Firefox

[ChristianFillon]

Hi Same thing with Chrome, using latest branch release/v1.1.0. Thank's for this description, I thought it was a mistake on my part. I also found a description here: https://issueexplorer.com/issue/metaplex-foundation/metaplex/512. Christian

[neurofoo]

@soulsayer9029 did you already init the store? if so, are you on devnet? Sometimes I've had to force the network by appending ?network=devent in the URL.

[ChristianFillon]

Hi. Happy new year. I tried this morning from home, with a good network. After a long time, I had an "out of memory" message on the Chrome tab, but not all the memory is not used on the computer. It seems it is a Chrome limitation or a memory leak. I haven't init the store, it is my first using of Metaplex, not so easy... Using this URL: http://localhost:3000/#/?network=devnet

Warning: Can't perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in a useEffect cleanup function. at MetaProvider (http://localhost:3000/_next/static/chunks/src_App_tsx.js:482228:25) at StoreProvider (http://localhost:3000/_next/static/chunks/src_App_tsx.js:483231:26)

There's a long log with the same information, a short example:

------->set finished running queued update currently another update is running, so queue for 3s... not running queued update right now, still loading -----> Query started ------->No pagination detected not running queued update right now, still loading pulling optimized nfts Pulling editions for optimized metadata Edition size 0 0 not running queued update right now, still loading ------->Query finished no update is running, updating. currently another update is running, so queue for 3s... ------->set finished not running queued update right now, still loading -----> Query started ------->No pagination detected pulling optimized nfts Pulling editions for optimized metadata Edition size 0 0 not running queued update right now, still loading

[neurofoo]

hmm.

A few things. You might have already done these. (caveats, I'm new to this codebase too!)

Is your .env empty? Make sure you don't have anything defined for REACT_APP_STORE_OWNER_ADDRESS_ADDRESS

For the devtools console, you should see output about store owner and address. Those should be undefined. If they aren't, then I think that the code thinks the store has been initialized.

Try in incognito mode. I just tried and even with a store configured in incognito mode I get the init screens to show. Not sure why it would be doing that in incognito, but this might be a base test too.

[aheff]

Has anyone made more progress with this? I am also new to this whole Metaplex thing. I managed to initialise a store on the mainnet beta and even create a few NFTs. The loading phase was taking a while; now it won't load at all and gets stuck on the 'just loading' screen like the people above.

Edit: I later found this page which is presumably the same issue - something to do with loading too much into memory. My Activity Monitor does show Brave Browser going made when I try and open the page...

Running on Mac OS.

[ChristianFillon]

@neurofoo I checked your idea of leaving the .env file empty. In this situation, there is no longer the infinite loading because there is no attempt to load because of the incomplete configuration. But then it is not possible to connect the wallet because there must be a check between the wallet address and the address given in the .env file. This test shows that the error is more precisely in the step of loading information to the Solana network, the "devnet" in my case. All the tutorials specify that the wallet address must be entered in the .env file, I think this instruction must be respected and that the problem is elsewhere.

[ChristianFillon]

Any news on this subject

[stegaBOB]

We are aware of the issue and are working on a fix

[DeltaMichael]

Still facing this, even tried deploying an older commit (tag v1.0.0), but still running into the issue. https://deltamichael.github.io/metaplex#/

A bit confused because of the response on this issue, which looks like a duplicate. It says it's fixed in the latest release, but that's what started breaking for me initially. https://github.com/metaplex-foundation/metaplex/issues/1450

[mrmizz]

minting crashes my chrome browser. general usage is horribly slow as well. I guess back to custom development . . .

breadcrumbs.ts:111 Warning: React has detected a change in the order of Hooks called by LaunchStep. This will lead to bugs and errors if not fixed. For more information, read the Rules of Hooks: https://reactjs.org/link/rules-of-hooks

   Previous render            Next render
   ------------------------------------------------------
1. useState                   useState
2. useState                   useState
3. useEffect                  useEffect
4. useEffect                  useEffect
5. undefined                  useContext
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    at LaunchStep (webpack-internal:///./src/views/artCreate/index.tsx:1781:54)
    at div
    at eval (webpack-internal:///../../node_modules/antd/es/grid/col.js:49:62)
    at div
    at eval (webpack-internal:///../../node_modules/antd/es/grid/row.js:45:34)
    at ArtCreateView (webpack-internal:///./src/views/artCreate/index.tsx:72:83)
    at component
    at Route (webpack-internal:///../../node_modules/react-router/esm/react-router.js:450:29)
    at Switch (webpack-internal:///../../node_modules/react-router/esm/react-router.js:652:29)
    at main
    at Basic (webpack-internal:///../../node_modules/antd/es/layout/layout.js:72:25)
    at Adapter (webpack-internal:///../../node_modules/antd/es/layout/layout.js:55:66)
    at section
    at BasicLayout (webpack-internal:///../../node_modules/antd/es/layout/layout.js:87:63)
    at Adapter (webpack-internal:///../../node_modules/antd/es/layout/layout.js:55:66)
    at section
    at BasicLayout (webpack-internal:///../../node_modules/antd/es/layout/layout.js:87:63)
    at Adapter (webpack-internal:///../../node_modules/antd/es/layout/layout.js:55:66)
    at _c (webpack-internal:///./src/components/Layout/index.tsx:68:27)
    at ConfettiProvider (webpack-internal:///./src/components/Confetti/index.tsx:24:3)
    at LoaderProvider (webpack-internal:///./src/components/Loader/index.tsx:21:3)
    at MetaProvider (webpack-internal:///../common/dist/lib/contexts/meta/meta.js:41:25)
    at StoreProvider (webpack-internal:///../common/dist/lib/contexts/store.js:27:26)
    at CoingeckoProvider (webpack-internal:///./src/contexts/coingecko.tsx:50:3)
    at SPLTokenListProvider (webpack-internal:///./src/contexts/tokenList.tsx:36:3)
    at AccountsProvider (webpack-internal:///../common/dist/lib/contexts/accounts/accounts.js:116:29)
    at WalletModalProvider (webpack-internal:///../common/dist/lib/contexts/wallet.js:83:32)
    at WalletProvider (webpack-internal:///../../node_modules/@solana/wallet-adapter-react/lib/WalletProvider.js:25:27)
    at WalletProvider (webpack-internal:///../common/dist/lib/contexts/wallet.js:116:27)
    at ConnectionProvider (webpack-internal:///../common/dist/lib/contexts/connection.js:57:31)
    at Providers (webpack-internal:///./src/providers.tsx:28:3)
    at Router (webpack-internal:///../../node_modules/react-router/esm/react-router.js:81:30)
    at HashRouter (webpack-internal:///../../node_modules/react-router-dom/esm/react-router-dom.js:103:35)
    at Routes
    at App
    at LoadableImpl (webpack-internal:///../../node_modules/next/dist/shared/lib/loadable.js:107:36)
    at App
    at div
    at App (webpack-internal:///./src/pages/_app.tsx:25:3)
    at ErrorBoundary (webpack-internal:///../../node_modules/@next/react-dev-overlay/lib/internal/ErrorBoundary.js:26:47)
    at ReactDevOverlay (webpack-internal:///../../node_modules/@next/react-dev-overlay/lib/internal/ReactDevOverlay.js:86:23)
    at Container (webpack-internal:///../../node_modules/next/dist/client/index.js:225:1)
    at AppContainer (webpack-internal:///../../node_modules/next/dist/client/index.js:604:3)
    at Root (webpack-internal:///../../node_modules/next/dist/client/index.js:734:3)

[shudhanshu-in]

Any Update on this issue ???

[mer0x]

any news ?

[arshia21]

For me the problem was gone when I changed to mainnet and added some actual SOL to the market owner address, and also to the Phantom wallet address

[v-raja]

Did you have to pay actual SOL to initialize the store or did just having some SOL in the wallet make it work?

On Mon, 31 Jan 2022 at 16:59, Arshia @.***> wrote:

For me the problem was gone when I changed to mainnet and added some actual SOL to the market owner address, and also to the Phantom wallet address

— Reply to this email directly, view it on GitHub https://github.com/metaplex-foundation/metaplex/issues/1339#issuecomment-1025996598, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJ44C7QFQWLF5E2FUSI34LLUY25WHANCNFSM5K4CRFHQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[mer0x]

Are you sure it s not just cached on local? For me when I try to access the website from a new browser it takes 1-2 minutes for first connection, 10-15 seconds after this, It seems this problem doesn t have any fix yet

[arshia21]

Yes, I had to pay around 0.004 actual SOL to initialise the store. Still it takes 1-2 minutes for first connection, but it i couldn't get it connected on devnet at all

[mapleflavor]

I just ran a build and same issues as you are all having. I tested with SOL in the wallet and still having issues. I'm running the test on github pages with no luck and perpetual loading still.

[stegaBOB]

Sorry for the lack of a quicker update. The issue right now is the speed at which you can query NFTs off chain. Sorting and querying all the NFTs from the blockchain isn't a really fast operation at this time since there's ~6,000,000 Solana NFTs it needs to sort through. Getting an indexer of some kind up and running is a solution that is currently been worked on which would solve this issue. I know this isn't the best of news, but unfortunately there isn't really a better option until a faster indexer is ready. Until then the initial loading time is just going to be slower than we'd like.

[ChristianFillon]

So metaplex is dead ? No solution to use it ?

[stegaBOB]

For the time being with storefront V1 (we are hard at work on a fully revamped v2), loading times are going to be slower (10s+ on fast rpc endpoints for larger collections) than we would like. There are quite a lot more things that Metaplex does than storefronts though, so I wouldn't say Metaplex is dead in the slightest. Regardless, the storefront will be getting better soon.

[mrmizz]

@stegaBOB can you speak a little as to why it is necessary to naively query the entire set of NFTs to initialize a storefront? that doesn't seem intuitive as clients are really just interested in specific NFTs of a given storefront.

[stegaBOB]

Unlike on Ethereum or other EVM chains, all NFTs on Solana are native SPL tokens. This means that in order to get the NFTs you want, the RPC nodes have to look through every Token Metadata account to find the NFTs with the matching metadata that you are looking for. This is why indexing by specific byte offsets will be really important in the future.

[v-raja]

Apologies if this is a naive question but how will the v2 storefront solve this?

[stegaBOB]

In theory, with more effecient react, a faster UI, and ideally an indexer that works will be reased by then.

[mrmizz]

@stegaBOB however on the solana chain you can easily query for all SPL tokens associated/minted by a given public-key.

[Conmmander]

I do not think V2 has solved this issue.

I am running v2 (or should be) on a github pages setup and experience quite slow landing on the main page. Typically it takes 2-3 minutes to load in an incognito window on Chrome. If I am in a regular chrome instance, it may not load at all (note I close the phantom wallet prompt and the "error" prompt shows up quickly, so I know that response time should be semi-fast.

I'm wondering if this is a git pages issue or another altogether. I'll throw the same instance together into a webserver and report back.

[nullmicgo]

After waited for a while, it shows the following error Error: 503 Server Overloaded: {"jsonrpc":"2.0","error":{"code":503,"message":"Server Overloaded"},"id": null}

[facetimer]

Any news?

[andrereus]

is there at least a possible workaround?

[andrereus]

how are some popular stores who are using metplex solving this problem? they seem to be faster

[stegaBOB]

I do not think V2 has solved this issue.

I am running v2 (or should be) on a github pages setup and experience quite slow landing on the main page. Typically it takes 2-3 minutes to load in an incognito window on Chrome. If I am in a regular chrome instance, it may not load at all (note I close the phantom wallet prompt and the "error" prompt shows up quickly, so I know that response time should be semi-fast.

I'm wondering if this is a git pages issue or another altogether. I'll throw the same instance together into a webserver and report back.

V2 isn't out yet. That's probably why it hasn't solved the issue haha. As of now the only workaround that doesn't involve a backend would be to build a custom caching/indexing layer into your storefront. This is what Holaplex has done I believe. Without that indexing layer, the problem is the slow read speed for RPCs. Until a caching/indexing layer is built on top of the rpcs, the speed of the current storefront will unfortunately just continue to slow down as the number of mints increases. A potential improvement in the meantime would be to replace all the current getProgramAccounts with a GPA that has a data size of 0. This returns the request a bit faster from there you can use getMultipleAccounts with up to 100 at a time to get the full necessary data (aka paginate it!).

Orrrrr if you want to do something a bit different and really dig into the weeds you can hardcode the mint addresses into the GPA calls and update those when you want to either mint a new token or something like that (or maybe use the mint list when a user goes to your site and then have the GPA calls run in the background and update your mint list in a backend database which can then update the mintlist on the frontend if needed).

All of these are short term "solutions" that are out of the scope of what we will do in the short term, but we would gladly review/merge any PR that implements a solution like that.

[EzanAsif]

Still getting this issue. Any solution for this?

[flatplate]

I had the same issue and the problem for me was that I had the wrong node version. Readme says version v14.17.6 and I had v16. After installing the proper version using nvm the problem was fixed.

[surgieboi]

Is there a fix for this? On localhost it takes 2-3 minutes and on Vercel, even longer.

[miukki]

i use 14.18.1 version and I have perpetual loading. and i believe it is related fetching nft is very long process

[miukki]

why you closed issue? @stegaBOB

[deeplearn-art]

Since this issue makes storefront unusable, it would be courteous to reference it in the README until fixed, so as not to disappoint people who wish to open up a custom NFT store on mainnet.

[ShaneDeconinck]

I'm also not able to get the Metaplex storefront running

[mnedelko]

Hello. Was wondering whether there is an update on this issue. I also experience the perpetually loading screen.

[ljuliandicarlo]

I've tried a few things: deleting .env / .env.production, clearing cash on both browser and Phantom, and reinstalling dependencies. Nothing worked -- still experiencing excessive load times at home page. Anyone know what the issue is here?

[mikecann]

Sooo.. why is this issue closed? It definately is not solved using the latest version..

Edit: noticed another issue opened for this here: https://github.com/metaplex-foundation/metaplex/issues/2043

[jester91]

Hi! I'm having the same issue with v2. I tried to deploy the code to GitHub pages, and run on localhost, and localhost/devnet but still facing the same issue. Tried to run the page(yarn start) from metaplex/js folder and metaplex/js/packages/web

[planktonrobo]

Same issue months later. Should not be closed

[Nedi11]

I also have the same issue.

[gabazureus]

Any news? Can't use it effectively :( Someone can develop a solution to this loading please, sir

[Marchccc]

so disappointed

[asifhassansoc]

any solution ?

[tastycrackers]

same here..very frustrating. Devs, can't solve this ? any improvement will be much appreciated!

[coladimeji]

My metaplex was slow when deployed in localhost and to preview- production It was suggested I use API, and I did, the local host is loading in less than 5 seconds but the preview-prod loads on the average 2.48 minutes any solution/ suggestion

[tastycrackers]

Found this: https://stackoverflow.com/questions/72300280/metaplex-storefront-on-vercel-perpetual-loading-problem