Front-End and UI Components

Nyvo’s front-end library includes pre-made UI components (buttons, forms, charts) that are bound to the dApp’s state. For example, a Connect Wallet component is provided, which uses Solana Wallet Adapter under the hood to handle Phantom, WalletConnect, etc. For each module, Nyvo has tailored components: a ProposalList component for governance, a StakePoolCard for showing staking pool stats, and so on. These components call the Nyvo API functions mentioned above when users interact with them. The internal structure is akin to a design system for web3 – developers can assemble pages using these components or edit them as needed, but the heavy logic is encapsulated.

The front-end also includes an Event Listener or subscription mechanism to refresh data. Nyvo might integrate with Solana’s websocket subscriptions or use a polling strategy to update the UI. For instance, after a transaction is confirmed (the promise returned by the send transaction is resolved), the Nyvo SDK could automatically fetch the affected accounts’ new data and update application state (perhaps using a state management like Redux or React Context). This means as a developer using Nyvo, you rarely have to write code to manually query accounts after every transaction – it’s handled by the framework.

Another aspect of the Nyvo API is error abstraction. Solana programs return error codes if something goes wrong. Nyvo’s API intercepts these and can throw human-readable exceptions or messages. Instead of seeing a raw error like custom program error: 0x1 on the front-end, Nyvo might map that to “Staking: Insufficient funds to stake” for clarity. The API reference would list common errors for each module and their meaning, so developers know how to handle them or display them. This is part of making the developer experience more like using a high-level SDK than dealing with raw blockchain calls.