Skip to content

deprecated-near-apps/nearbp

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

29 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Live App Review 1 - App Access Keys

This repo is a companion to this video:

Live App Review 1 - App Access Keys

Feedback (TODO)

Will there be an option to test / run app against a contract that is long lived on testnet? Use case: shared data sets, more testability, better starting point Separate script for shared namespace

Server should include warning if config loaded is not current dev account, ping dev folder and crash and restart

Step by step high level (matching what's in the frontend)

Better installation guide / step by

Question: why create brand new dev accounts every time? Why not have a consistent namespace for your app? Destroy / RE-create same name. Answer: dev accounts for rapid iteration, then deploy to serious name (accidental deploy over existing account?)

Kitchen Sink npm library for near dev build scripts and utils???

Installation

Beyond having npm and node (latest versions), you should have Rust installed. I recommend nightly because living on the edge is fun.

https://rustup.rs/

Also recommend installing near-cli globally

npm i -g near-cli

Everything else can be installed via: yarn cd server && yarn

NEAR Config

There is only one config.js file found in src/config.js, this is also used for running tests.

Using src/config.js you can set up your different environments. Use REACT_APP_ENV to switch environments e.g. in package.json script deploy.

Running Tests

You can run unit tests in the Rust contracts themselves, but it may be more useful to JS tests against testnet itself.

Note: to run the app and server tests make sure you install and start the server.

  • cd server
  • yarn && yarn start

Commands:

  • test will simply run app tests against the contract already deployed. You can mess around with app.test.js and try different frontend stuff
  • test:deploy - will deploy a new dev account (/neardev) and deploy a new contract to this account, then run test
  • test:server - will test the server, make sure you start it (see "Note" above)
  • test:unit - runs the rust unit tests

If you've changed your contract or your dev account has run out of funds use test:deploy, if you're updating your JS tests only then use test.

Test Utils

There are helpers in test/test-utils.js that take care of:

  1. creating a near connection and establishing a keystore for the dev account
  2. creating test accounts each time a test is run
  3. establishing a contract instance so you can call methods

You can change the default funding amount for test accounts in src/config.js

Using the NEAR Config in your app

In src/state/near.js you will see that src/config.js is loaded as a function. This is to satisfy the jest/node test runner.

You can destructure any properies of the config easily in any module you import it in like this:

// example file app.js

import getConfig from '../config';
export const {
	GAS,
	networkId, nodeUrl, walletUrl, nameSuffix,
	contractName,
} = getConfig();

Note the export const in the destructuring?

Now you can import these like so:

//example file Component.js
import { GAS } from '../app.js'
...
await contract.withdraw({ amount: parseNearAmount('1') }, GAS)
...

React 17, Parcel with useContext and useReducer

  • Bundled with Parcel 2.0 (@next) && eslint
  • Minimal all-in-one state management with async/await support

Getting Started: State Store & useContext

The following steps describe how to use src/utils/state to create and use your own store and StateProvider.

  1. Create a file e.g. /state/app.js and add the following code
import { State } from '../utils/state';

// example
const initialState = {
	app: {
		mounted: false
	}
};

export const { store, Provider } = State(initialState);
  1. Now in your index.js wrap your App component with the StateProvider
import { Provider } from './state/app';

ReactDOM.render(
    <Provider>
        <App />
    </Provider>,
    document.getElementById('root')
);
  1. Finally in App.js you can useContext(store)
const { state, dispatch, update } = useContext(store);

Usage in Components

Print out state values

<p>Hello {state.foo && state.foo.bar.hello}</p>

Update state directly in component functions

const handleClick = () => {
    update('clicked', !state.clicked);
};

Dispatch a state update function (action listener)

const onMount = () => {
    dispatch(onAppMount('world'));
};
useEffect(onMount, []);

Dispatched Functions with context (update, getState, dispatch)

When a function is called using dispatch, it expects arguments passed in to the outer function and the inner function returned to be async with the following json args: { update, getState, dispatch }

Example of a call:

dispatch(onAppMount('world'));

All dispatched methods and update calls are async and can be awaited. It also doesn't matter what file/module the functions are in, since the json args provide all the context needed for updates to state.

For example:

import { helloWorld } from './hello';

export const onAppMount = (message) => async ({ update, getState, dispatch }) => {
	update('app', { mounted: true });
	update('clicked', false);
	update('data', { mounted: true });
	await update('', { data: { mounted: false } });

	console.log('getState', getState());

	update('foo.bar', { hello: true });
	update('foo.bar', { hello: false, goodbye: true });
	update('foo', { bar: { hello: true, goodbye: false } });
	update('foo.bar.goodbye', true);

	await new Promise((resolve) => setTimeout(() => {
		console.log('getState', getState());
		resolve();
	}, 2000));

	dispatch(helloWorld(message));
};

Prefixing store and Provider

The default names the State factory method returns are store and Provider. However, if you want multiple stores and provider contexts you can pass an additional prefix argument to disambiguate.

export const { appStore, AppProvider } = State(initialState, 'app');

Performance and memo

The updating of a single store, even several levels down, is quite quick. If you're worried about components re-rendering, use memo:

import React, { memo } from 'react';

const HelloMessage = memo(({ message }) => {
	console.log('rendered message');
	return <p>Hello { message }</p>;
});

export default HelloMessage;

Higher up the component hierarchy you might have:

const App = () => {
	const { state, dispatch, update } = useContext(appStore);
    ...
	const handleClick = () => {
		update('clicked', !state.clicked);
	};

	return (
		<div className="root">
			<HelloMessage message={state.foo && state.foo.bar.hello} />
			<p>clicked: {JSON.stringify(state.clicked)}</p>
			<button onClick={handleClick}>Click Me</button>
		</div>
	);
};

When the button is clicked, the component HelloMessage will not re-render, it's value has been memoized (cached). Using this method you can easily prevent performance intensive state updates in further down components until they are neccessary.

Reference:

Releases

No releases published

Packages

No packages published

Languages