.gitpod.yml
README.md
contract
    README.md
    build.sh
    deploy-prod.sh
    deploy.sh
    package.json
    src
        contract.ts
        helpers.ts
        types.ts
    tsconfig.json
integration-tests
    package.json
    src
        _setup.ts
        event_lists.ava.ts
        events.ava.ts
near.social
    .env
    .eslintrc.json
    .prettierrc.js
    deploy.js
    dev.js
    package.json
    shared.js
    widgets
        app
            .env
        events
            .env
package.json

Near Events
==================

This app was initialized with [create-near-app]

Quick Start
===========

If you haven't installed dependencies during setup:

    yarn

Build and deploy your contract to *Mainnet*:

    NEAR_ENV=mainnet near login
    yarn build
    NEAR_ENV=mainnet deploy --accountId YOUR_ACCOUNT_ID_ON_MAINNET --wasmFile contract/build/events.wasm

Exploring The Code
==================

1. The smart-contract code lives in the `/contract` folder. See the README there for
   more info. In blockchain apps, the smart contract is the "backend" of your app.
2. The near.social code lives in the `/near.social` folder.
3. Test your contract: `yarn test`, this will run the tests in the `integration-tests` directory.

Development
===========

0. Adjust Environment Variables in `near.social/.env` file
1. Run the local development environment:

    NEAR_ENV=mainnet yarn start

This will start the local near.social dev-server which will automatically redeploy your widgets on near.social mainnet when you change the code in the `widgets` folder.

## Features

1. Automatic redeployment:
    Widgets will automatically be redeployed on near.social when you change the code in the `widgets` folder.
2. Automatic widget registration:
    Widgets will be named after the folder they are in, so if you want to deploy a widget called `my-widget`, you should
    create a file called `component.jsx` in the `widgets` folder. Nested folders will be flattened, so if you
    you create a file called `my-widget/component.jsx`, the widget will be named `my-widget__component` on near.social.
3. env var substitution:
    You can use environment variables in your widget code. For example, any occurence of `{{ env.MY_VAR  }}` will be replaced with
    the value of the `MY_VAR` environment variable from an .env file. .env files are loaded from the `widgets` folder
    and from the widget file's context. For example, if you have a file called `widgets/my-widget/.env`
    and a file called `widgets/my-widget/component.jsx`, the .env file will be loaded for the `component.jsx` file.
    This works recursively, so if you have a file called `widgets/.env` and a file called `widgets/my-widget/nested/component.jsx`,
    the .env file will also be loaded for the `component.jsx` file. Only the topmost .env file will be loaded for each widget file.
    If you want a widget to have its own .env file, you can create a folder for it and put the .env file in that folder. For example,
    if you have a file called `widgets/my-widget/component.jsx` and a file called `widgets/my-widget/component/.env`,
    the .env file will be loaded for the `component.jsx` file, but not for any other widget files except for child widget files in the
    `component` folder.
4. Speed
    Widgets will be deployed on near.social as soon as you change the code in the `widgets` folder. This means that you can
    develop your widgets locally and deploy them on near.social as soon as you're ready.
5. App-like structure
   Widgets following this structure will have access to common components and utilities:
    1. Widgets can render child widgets by referencing their names (e.g. `renderComponent('some_widget.child.another', {})`).
    2. Widgets can within layouts (e.g. `renderComponent('some_widget.child.another', {}, 'container')`).
    3. Router with methods for navigating between pages (e.g. `push('some_widget')` and `pop()`).
    4. Shared Components (e.g. `props.__engine.Components.Button`).
    5. Overlays/Modals via layouts (e.g. `renderComponent('some_widget.child.another', {}, 'modal')`). This is useful for
       widgets that need to render a modal on top of the current page.

## Structure

1. `widgets` folder:
    This folder contains all the widgets that will be deployed on near.social. Each widget should be in its own folder.
    The folder name will be used as the widget name. For example, if you have a file called `widgets/my-widget/component.jsx`,
    the widget will be named `my-widget__component` on near.social. Nested folders will be flattened, so if you
    you create a file called `my-widget/parent/component.jsx`, the widget will be named `my-widget__parent__component` on near.social.
2. `widgets/.env` file:
    This file contains environment variables that will be used for all widgets. You can override these variables in the
    widget's .env file.
3. *TODO*: automatic upload of widget metadata
   1. - [ ] read metadata file from disc
   2. - [ ] check if image files from metadata file exist on ipfs
   3. - [ ] upload images from metadata file to ipfs
   4. - [ ] set metadata file for widget

## Open TODOs

- [ ] refactor layouting mechanism to be able to register layouts from within the component. This enables us to use to save the state of the router in the Storage, Currently callbacks like onClick cannot be saved to Storage, which causes the state of the router to be lost when the page is refreshed.
- [ ] metadata support for widgets (not a pressing issue, can be done in the web-ui)
- [ ] purging of all widgets of a user

Later:

- [ ] VSCode extension for widget development (live preview, mocking of widgets)

Deploy
======

Every smart contract in NEAR has its [own associated account][NEAR accounts].
When you run `yarn deploy`, your smart contract gets deployed to the live NEAR *TestNet* with a temporary dev account.
When you're ready to make it permanent, here's how:

Step 0: Install the `near-cli` (optional)
-------------------------------------

[near-cli] is a command line interface (CLI) for interacting with the NEAR blockchain. It was installed to the local
`node_modules` folder when you ran `yarn`, but for best ergonomics, you may want to install it globally:

    yarn global add near-cli

Or, if you'd rather use the locally-installed version, you can prefix all `near` commands with `yarn`

Ensure that it's installed with `near --version` (or `yarn near --version`)

Step 1: Create an account for the contract
------------------------------------------

Each account on NEAR can have at most one contract deployed to it. If you've already created an account such as
`your-name.testnet`, you can deploy your contract to `near-blank-project.your-name.testnet`. Assuming you've
already created an account on [NEAR Wallet], here's how to create `near-blank-project.your-name.testnet`:

1. Authorize NEAR CLI following the commands it gives you:

      near login

2. Create a subaccount (replace `YOUR-NAME` below with your actual account name):

      near create-account near-blank-project.YOUR-NAME.testnet --masterAccount YOUR-NAME.testnet

Step 2: Deploy the contract
---------------------------

Use the CLI to deploy the contract to TestNet with your account ID.
Replace `PATH_TO_WASM_FILE` with the `wasm` that was generated in the `contract` build directory.

    near deploy --accountId near-blank-project.YOUR-NAME.testnet --wasmFile PATH_TO_WASM_FILE

-----------------------------------------------

Troubleshooting
===============

On Windows, if you're seeing an error containing `EPERM` it may be related to spaces in your path. Please see
[this issue](https://github.com/zkat/npx/issues/209) for more details.

  [create-near-app]: https://github.com/near/create-near-app
  [NEAR accounts]: https://docs.near.org/concepts/basics/account
  [NEAR Wallet]: https://wallet.testnet.near.org/
  [near-cli]: https://github.com/near/near-cli
# Events platform smart contract

# Quickstart

1. Make sure you have installed [node.js](https://nodejs.org/en/download/package-manager/) >= 16.
2. Install the [`NEAR CLI`](https://github.com/near/near-cli#setup)

<br />

## 1. Build and Deploy the Contract

You can automatically compile and deploy the contract in the NEAR testnet by running:

```bash
yarn run deploy
```

Once finished, check the `neardev/dev-account` file to find the address in which the contract was deployed:

```bash
cat ./neardev/dev-account
# e.g. dev-1659899566943-21539992274727
```

<br />

## 2. Create an event

`create_event` changes the contract's state, so it is a `call` method.

`Call` methods can only be invoked using a NEAR account since the account needs to pay GAS for the transaction.

```bash
# Use near-cli to create a new event
near call <dev-account> create_event '{"name":"test","type":"irl","category":"test","status":"published","description":"test","start_date":"2023-01-11T14:54:06.652Z","end_date":"2023-01-12T14:54:06.652Z","location":"here","image":[],"links":[]}' --accountId <dev-account> --deposit 1
```

**Tip:** If you would like to call `create_event` using your account, first login into NEAR using:

```bash
# Use near-cli to login your NEAR account
near login
```

and then use the logged account to sign the transaction: `--accountId <your-account>`.

<br />

## 3. Get an existing event

`get_event` does not change the contract state, it only reads it so it is a `view` method.

`View` methods can be called for **free** by anyone, even people **without a NEAR account**!

```bash
# Use near-cli to get an existing event
near view <dev-account> get_event '{"event_id":"test"}'
```

<br />

## 4. Get all existing events

`get_all_events` does not change the contract state, it only reads it so it is a `view` method.

```bash
# Use near-cli to get all existing events
near view <dev-account> get_all_events '{}'
```

<br />

## 5. Get all events created by a specified account ID

`get_all_events_by_account` does not change the contract state, it only reads it so it is a `view` method.

```bash
# Use near-cli to get all existing events
near view <dev-account> get_all_events_by_account '{"account_id":"<dev-account>"}'
```

<br />

## 6. Update an existing event

`update_event` changes the contract's state, so it is a `call` method.

```bash
# Use near-cli to update an existing event
near call <dev-account> update_event '{"event_id":"test","event":{"description":"test2"}}' --accountId <dev-account>
```

**Note:** Keep in mind that if you created the event with your account you will also have to update it using the same account.

<br />

## 7. Delete an existing event

`remove_event` changes the contract's state, so it is a `call` method.

```bash
# Use near-cli to delete an existing event
near call <dev-account> remove_event '{"event_id":"test"}' --accountId <dev-account>
```

**Note:** Keep in mind that if you created the event with your account you will also have to delete it using the same account.
