rainlanguage / rain-studio

Rain Studio is the ultimate platform for creating smart contracts and blockchain-based applications using Rainlang.

create-svelte

Everything you need to build a Svelte project, powered by create-svelte.

Creating a project

If you're seeing this, you've probably already done this step. Congrats!

# create a new project in the current directory
npm create svelte@latest

# create a new project in my-app
npm create svelte@latest my-app

Developing

Once you've created a project and installed dependencies with npm install (or pnpm install or yarn), start a development server:

npm run dev

# or start the server and open the app in a new browser tab
npm run dev -- --open

Building

To create a production version of your app:

npm run build

You can preview the production build with npm run preview.

To deploy your app, you may need to install an adapter for your target environment.

rain-studio's Issues

App crash when trying to accces to /user/"username"/expressions when not logged

This happened to me when the session end meanwhile I was checking expressions dashbord.

The app crash with an 500 Internal Error with this on the server side:

Invalid "number" argument: NaN
RangeError: Invalid "number" argument: NaN
    at parseNumber (/home/nanez/terra-virtua/rain-studio/node_modules/relative-time-format/commonjs/RelativeTimeFormat.js:455:13)
    at parseFormatArgs (/home/nanez/terra-virtua/rain-studio/node_modules/relative-time-format/commonjs/RelativeTimeFormat.js:485:11)
    at RelativeTimeFormat.format (/home/nanez/terra-virtua/rain-studio/node_modules/relative-time-format/commonjs/RelativeTimeFormat.js:160:30)
    at TimeAgo.formatDateForStep (/home/nanez/terra-virtua/rain-studio/node_modules/javascript-time-ago/commonjs/TimeAgo.js:337:48)
    at TimeAgo.format (/home/nanez/terra-virtua/rain-studio/node_modules/javascript-time-ago/commonjs/TimeAgo.js:233:32)
    at TimeAgo.svelte:14:27
    at Object.$$render (/node_modules/svelte/internal/index.mjs:1876:22)
    at eval (/src/lib/expressions/ExpressionRow.svelte:25:88)
    at Object.$$render (/node_modules/svelte/internal/index.mjs:1876:22)
    at eval (/src/lib/expressions/DeployedExpressionSummaryRow.svelte:45:108)

To reproduce this error, as I said before, just logout and tried to access to any user expressions dashbourd like /user/nanezx/expressions and the app will crash.

performance improvements for parser and user expression page

add undo/redo to parser in studio app

Detail page for deployed expressions

Improve search/selection for contracts

Same for contracts, we need to be able to filter by

• Networks
• Contract

And search by name or deployed address on any network.

The card should show the networks that contract is deployed on

Mobile styling

Redirect when try to access to user/"username"/expression route to another page

Remove the bottom bar from the SImulator in Breaking down an expression

https://studio.rainprotocol.xyz/docs/breaking-down-an-expression

X-browser testing

Design how and when the users could see and star/like expressions

There are missing scenarios that we still need to cover related to the visibility of the draft expressions and how the user can interact with them. The main scenarios that have been considered so far with Josh:

• Scenario 1: I have a private expression and I share it with you via a sharable link. You star it. Now, I replace the sharable link (as you described above). So, I don’t want it to appear in your starred expressions anymore either. Scenario 1 is maybe only possible if you starred the sharable slug, not the actual draft_expression id. Because even if I replace the sharable slug, it won’t change the id.

• Scenario 2: I made an expression public and you discovered it in some public feed/community showcase/elsewhere. You starred it. Now, I want to make it private again, so I don’t want it to appear in your starred expressions. Scenario 2 seems easy on its own. You just never return private expressions when a user queries their starred expressions. But it’s more complicated when you consider the above.

• Scenario 3: you share me a private expression via sharable link, i star it. Then you make it public. THEN, you replace the sharable link. So even though I starred it via sharable link and that link doesn’t exist anymore, I should still have it starred because now it’s public anyway.

Probably there’s other scenarios that are a mix of all of the above.

Add filters to user expressions page

Add environment and release URL to sentry releases

Also need to get sourcemap uploading working

Improvements to wallet link design and UX

PR on #17

Page on profile needs updating to latest design:

Confirmation modal for unlinking a wallet (check the 'are you sure you want to delete this expression') modal on user/[user]/expressoins

Show current linked wallet in profile dropdown (and "Connect wallet" in its place if no wallet is connected yet):

On first connecting a wallet (on any screen, this is global across the app), or switching addresses, show a modal if the connected wallet isn't linked to the user's account yet.

If they say 'no thanks' store this preference in local storage and don't ask again for that wallet address.

However, if the connected wallet isn't linked, always show the "link this wallet" CTA on the profile dropdown.

write help panel for IDE with links to tg dev ecosystem and docs

Organisations context

https://www.figma.com/file/2u2mk6rYmux66BO5oFP7Pn/Studio-Organisations-and-Teams?node-id=0%3A1&t=kxwDv6uoDFGZ3gJe-1

This is a placeholder until this task can be more fleshed out

Contexts

1. Me
2. Teams I'm part of e.g. Rain, BullFX
3. Communities I'm part of e.g. gaming (not for now)
4. Global e.g. all public stuff

Save mock context into db for recall

Improve Orderbook deploy experience

Specifically:

• Fix any GUI glitches, make errors more easily readable etc
• Feedback for when actually submitting the transaction
• Remove the deployed expressions from subgraph panel

When loading expressions into the parser on the contract Write tab, filter by the contract and expression type

expression fixes

Two things I noticed:

• Hiding the edit button on the view expression page if it isn't owned by the authenticated user
• Hiding any public expressions that aren't yours from the user expressions page

Show deployed expressions on user expression page

Update contract page to work with latest database changes

Studio homepage

hook up fork button on formatter and save button on parser in docs

(For beta) Remove dead links from app, put user expressions under main Expressions nav link

Update how the contracts are cached from SG to Supabase

It should be changed how the contracts from the Interpreter Subgraph are being use in the app. The main goal is add this contracts into supabase with their data decoded from the Meta Contract that is on chain AND still using the same structure that already have the studio. The following proposal is intended to achieve this:

Tables

- contract

The first proposal: would contain changes into new supabase tables where we can store the info and manage all the contracts with same bytecode, this will be using different tables.

This first table that will be created/extended is the contracts table that will hold the most of the decoded data like the ABI. And since the ID should be unique, we can generate an UUID from a bytecode hash got it using the Introspection Contract.

ID (uuid)*	bytecode_hash (test)*	abi (json)*	contract_meta (json)	project (uuid)	created_at (timestamp)*	slug (text)*	metadata (json)*
UUID from bytecode hash	The bytecode hash	ABI from the Rain document	The contract meta from the Rain document	UUID that have the relation to a project (could be null)	Timestamp when was added to table	Contract slug (or contract alias)	It will follow the current format but removing some field like known addresses

- contract_addresses

The second table will solve the issue that comes - how have a control about all the addresses that are the "same" (same bytecode) and over different chains. The contract_addresses will have an ID, the address, the chainId. Also this new table will have a relation with the contracts table that will help to found all the addresses that have an specific ID on contracts table. The table will have a constraint that indicate that the combination of address + chainId should be unique.

ID (uuid)*	contract (uuid)*	address (text)*	chainId (int8)*	created_at (timestamp)*	type (text)*
UUID generated from address + chainId	UUID that have the relation to a contract row	The address of the contract	The chain id where the contract is deployed	Timestamp when was added	Type of the contract like implementation or contract (or other way to categorize them)

- deployers

The table would change how all the interpreter related info is stored, so the workflow can focus on save as much information possible from the Subgraph into the database. The deployers table will save all the data related to the ExpressionDeployer it self, like his bytecode_hash, the opmeta, metadata to be used organized and used, etc.

ID (uuid)*	bytecode_hash (text)*	opmeta (json)*	created_at (timestamp)*
UUID from bytecode hash	The bytecode hash	The decoded Opmeta from the Rain document	Timestamp when was added

- deployers_addresses

This table allow the database store all the ExpressionDeployer address with even the same bytecode hash, which will help to organize them, save space in the database avoiding duplicated data. So, it will be possible query all the addresses for a given chain, found similar deployers for a given address, or other scenarios :)

ID (uuid)*	deployer (uuid)*	address (text)*	chainId (int8)*	created_at (timestamp)*
UUID generated from address + chainId	UUID that have the relation to a deployer row	The address of the deployer	The chain id where the deployer is deployed	Timestamp when was added

- rainterpreters

As previous tables, this table will be storing all the related info about a given rainterpreter contract based on his bytecode.
Basically, this info should come from the Interpreter in the Subgraph that hold all the data using the bytecode hash.

ID (uuid)*	bytecode_hash (text)*	created_at (timestamp)*
UUID from the bytecode hash	The bytecode hash of the Rainterpreter contract	Timestamp when was added

- rainterpreter_addresses

This table will store the particular information about each Rainterpreter contract. Similar than the rainterpreters table, the data basically will come from the Interpreter in the subgraph.

ID (uuid)*	rainterpreter (uuid)*	address (text)*	chainId (int8)*	created_at (timestamp)*
UUID generated from address + chainId	UUID that have the relation to a rainterpreter row	The address of the rainterpreter	The chain id where the rainterpreter is deployed	Timestamp when was added

- rainterpreter_stores

Currently, we have pretty simplest rainterpreterStore contracts on chain, but naturally new could be deployed by our updates, or some third party writing or updating his own contract. These tables propose a way to start working around that. Following the same pattern that it is done with the other tables, this two new tables will work as rainterpreter_stores and rainterpreter_store_addresses, so we can have the same benefits when someone search an specific address, could see other similar contracts with the same bytecode as etherscan does.

ID (uuid)*	bytecode_hash (text)*	created_at (timestamp)*
UUID from the bytecode hash	The bytecode hash of the RainterpreterStore contract	Timestamp when was added

- rainterpreter_store_addresses

ID (uuid)*	rainterpreter_store (uuid)*	address (text)*	chainId (int8)*	created_at (timestamp)*
UUID generated from address + chainId	UUID that have the relation to a rainterpreter_stores row	The address of the rainterpreter_stores	The chain id where the rainterpreter is deployed	Timestamp when was added

Metadata scheme

As was mentioned, the goal is use the current workflow that have the studio and avoid refactoring unnecessary things. The metadata is a great way to save all the relevant information about a contract that is necessary to his use. Almost all the fields will remain in the metadata with the exception of some of them like the addresses since is handled on a different way.

Metadata format that will go into contracts -> metadata column:

{
  "name": "",
  "source": "",
  "description": "",
  "inputs": ["input_1", "input_2"],
  "expressions": ["expression_1", "expression_2"]
}

Execution

- cron job

There must be a specific job that is executed from time to time to update the data in supabase. The contract meta obtained from the Subgraph should decoded using CBOR bases on their encoded and data type to be fully handled and save it into supabase tables with the specific and expected design. There are different ways to execute this, but the best way to do (at the time this is written) is use the GitHub workflows and using an schedule that run every X minutes.

By the previous reason the job should have a determinate access to the supabase project to write all this data. This could be achieve with using service_role API key that supabase provide. EDIT: So, we can use the pg_cron extension that supabase provide to schedule the edge function.

Design for /expressions

Clicking "detailed view" on a parser input on the contract write tab, opens the current expression in the IDE

Allow users to star/favourite expressions

This would need to support deployed expressions (by address) and draft expressions (by ID).

Only draft expressions with the new public flag can be favourited.

Probably need to create a new "starred" table

"address" and "foreign_key" should be mutually exclusive. we can write a postgres CONSTRAINT for this...

ALTER TABLE user_favourites
ADD CONSTRAINT foreign_key_or_address
CHECK (foreign_key IS NOT NULL OR address IS NOT NULL);

something like this

Design how and when the users could see and star/like expressions

There are missing scenarios that we still need to cover related to the visibility of the draft expressions and how the user can interact with them. The main scenarios that have been considered so far with Josh:

• Scenario 1: I have a private expression and I share it with you via a sharable link. You star it. Now, I replace the sharable link (as you described above). So, I don’t want it to appear in your starred expressions anymore either. Scenario 1 is maybe only possible if you starred the sharable slug, not the actual draft_expression id. Because even if I replace the sharable slug, it won’t change the id.

• Scenario 2: I made an expression public and you discovered it in some public feed/community showcase/elsewhere. You starred it. Now, I want to make it private again, so I don’t want it to appear in your starred expressions. Scenario 2 seems easy on its own. You just never return private expressions when a user queries their starred expressions. But it’s more complicated when you consider the above.

• Scenario 3: you share me a private expression via sharable link, i star it. Then you make it public. THEN, you replace the sharable link. So even though I starred it via sharable link and that link doesn’t exist anymore, I should still have it starred because now it’s public anyway.

Probably there’s other scenarios that are a mix of all of the above.

Allow arbitrary context on 'no contract' expressions

Add a public flag for expressions

Add a flag to the draft_expressions table so that users can make their draft expression publicly accessible.

Adjust the RLS policy so that select can be used to get all draft_expressions that have the flag.

CREATE POLICY select_public_draft_expressions
ON draft_expressions
FOR SELECT
USING (public = TRUE);

Show deployed expressions for a contract on the contract page

Show a feed of recently deployed expressions for the contract.

Match wallet addresses to user accounts where possible

Pls move to the sidebar, under the heading "recently deployed".

Eventually would match all known addresses across all chains.

Adjust the expressions page to give more width to the expression

set up mdsvex in project and convert onboarding docs to .svx

Make sure footer looks good on all pages

Improve search/selection interpreters

Choosing a deployer is crazy at the moment.

Easiest improvement would to be allow search - if someone has an address of a deployer they would like to use they can paste it in and then select it.

Possibly we just need another type of select field component?

Mobile styles for IDE and Profile pages

Update SG queries on Cron job to use pagination

There is a relevant issue on the cron job, because the queries are not returning all the entities that are stored. This is due the limitation of the response up to aprox 100 entities. Some possibles solutions are:

• Using pagination. See on thegraph docs. But maybe in future we need to use other approach when the data is too big (?) and slow to iterate.
• Another possible way is save the latest timestamp checked by the cron job on supabase

App crashes when loading the view page for a newly forked expression

Allow users to add tags to draft_expressions

Add view buttons to expressions summary on the expression and IDE

Also, on the summary row move "duplicate" and "delete" into an overflow menu

Add simulator to Studio

Resizable panels in IDE

https://orefalo.github.io/svelte-splitpanes/

Design how and when the users could see and star/like expressions

Design sweep

Get deploy working on contract page

add sentry to site

Add updated Simulator to Studio

Change sign in to use an ethereum wallet

https://docs.moralis.io/docs/web3-supabase-authentication

Fix hover for small light buttons

this hover style should be lighter