func-tolk flow

Author: aigerimu

docs/v3/guidelines/quick-start/developing-smart-contracts/blueprint-sdk-overview.mdx renamed to docs/v3/guidelines/quick-start/developing-smart-contracts/func-tolk-folder/blueprint-sdk-overview.mdx

@@ -26,11 +26,11 @@ This makes it possible to calculate the future wallet smart contract address.
 
 ### Magic storage member
 
-In previous steps, we deliberately didn't explain the purpose of `ctxID` and `ID` stored in our smart contract's state and why they remained untouched in all the smart contract functionality. Now, their purpose should start to become clearer.
+In previous steps, we deliberately didn't explain the purpose of `ctx_id` and `ID` stored in our smart contract's state and why they remained untouched in all the smart contract functionality. Now, their purpose should start to become clearer.
 
 Since we can't deploy a smart contract with the same `state_init`, the only way to provide the same initial code and **"same"** initial data is to create a separate field in it, ensuring additional uniqueness. This, in the case of a wallet, gives you the opportunity to have the same key pair for several wallet smart contracts.
 
-### One to rule them all
+{/*### One to rule them all
 
 If you've already considered that the `ID` field is a must-have for any smart contract, there is another opportunity that could change your mind. Let's examine the previously developed `CounterInternal` smart contract's init section:
 
@@ -47,10 +47,10 @@ If we remove the `id` field from its initial storage, we can ensure that **only
 :::info Tokens
 This mechanism plays a crucial role in [Jetton Processing](/v3/guidelines/dapps/asset-processing/jettons/). Each non-native (jetton) token requires its own `Jetton Wallet` for a particular owner and, therefore, provides a calculable address for it, creating a **star scheme** with the basic wallet in the center.
 :::
-
+*/}
 ## Implementation
 
-Now that our smart contracts are fully tested, we are ready to deploy them to TON. In `Blueprint SDK`, this process is the same for both `Mainnet` and `Testnet` and for any of the presented languages in the guide: `FunC`, `Tact`, or `Tolk`.
+Now that our smart contracts are fully tested, we are ready to deploy them to TON. In `Blueprint SDK`, this process is the same for both `Mainnet` and `Testnet` and for any of the presented languages in the guide: `FunC` or `Tolk`.
 
 ### Step 1: update the deployment script
 
@@ -59,7 +59,6 @@ Deployment scripts rely on the same wrappers that you have used in testing scrip
 ```typescript title="/scripts/deployHelloWorld.ts"
 import { toNano } from '@ton/core';
 import { HelloWorld } from '../wrappers/HelloWorld';
-import { CounterInternal } from '../wrappers/CounterInternal';
 import { compile, NetworkProvider } from '@ton/blueprint';
 
 export async function run(provider: NetworkProvider) {
@@ -78,23 +77,7 @@ export async function run(provider: NetworkProvider) {
 
     await provider.waitForDeploy(helloWorld.address);
 
-    const counterInternal = provider.open(
-        await CounterInternal.fromInit(
-            BigInt(Math.floor(Math.random() * 10000)),
-            helloWorld.address
-        )
-    );
-
-    await counterInternal.send(
-        provider.sender(),
-        { value: toNano('0.05') }, 
-        null
-    );
-
-    await provider.waitForDeploy(counterInternal.address);
-
     console.log('ID', await helloWorld.getID());
-    console.log('ID', (await counterInternal.getId()).toString());
 }
 ```
 

docs/v3/guidelines/quick-start/developing-smart-contracts/deploying-to-network.mdx renamed to docs/v3/guidelines/quick-start/developing-smart-contracts/func-tolk-folder/deploying-to-network.mdx

@@ -182,7 +182,7 @@ By combining both of these patterns, you can achieve a comprehensive description
 
 `External messages` are your only way of toggling smart contract logic from outside the blockchain. Usually, there is no need for implementation of them in smart contracts because, in most cases, you don't want external entry points to be accessible to anyone except you. If this is all the functionality that you want from the external section, the standard way is to delegate this responsibility to a separate actor - [wallet](v3/documentation/smart-contracts/contracts-specs/wallet-contracts#basic-wallets/), which is practically the main reason they were designed for.
 
-Developing external endpoints includes several standard [approaches](/v3/documentation/smart-contracts/message-management/external-messages/) and [security measures](/v3/guidelines/smart-contracts/security/overview/) that might be overwhelming at this point. Therefore, in this guide, we will implement incrementing the previously added `ctxCounterExt` number and add a send message to our `Tact` contract.
+Developing external endpoints includes several standard [approaches](/v3/documentation/smart-contracts/message-management/external-messages/) and [security measures](/v3/guidelines/smart-contracts/security/overview/) that might be overwhelming at this point. Therefore, in this guide, we will implement incrementing the previously added `ctx_counter_ext` number.
 
 :::danger
 This implementation is **unsafe** and may lead to losing your contract funds. Don't deploy it to `Mainnet`, especially with a high smart contract balance.
@@ -259,7 +259,7 @@ fun onExternalMessage(inMsg: slice) {
 </TabItem>
 </Tabs>
 
-This function, upon receiving an external message, will increment our `ctxCounterExt` and also send an internal message to the specified address with the `increase` operation, which we will use to increment the counter on our `CounterInternal` smart contract.
+This function, upon receiving an external message, will increment our `ctx_counter_ext` and also send an internal message to the specified address with the `increase` operation.
 
 Verify that the smart contract code is correct by running:
 
@@ -308,13 +308,12 @@ async sendExternalIncrease(
 
 ### Step 3: update test
 
-Update the test to ensure that the `HelloWorld` contract received the external message, sent an internal message to the `CounterInternal` contract, and both updated their counters:
+Update the test to ensure that the `HelloWorld` contract received the external message, and updated its counters:
 
 ```typescript title="/tests/HelloWorld.spec.ts"
 import { Blockchain, SandboxContract, TreasuryContract } from '@ton/sandbox';
 import { Cell, toNano} from '@ton/core';
 import { HelloWorld } from '../wrappers/HelloWorld';
-import { CounterInternal } from '../wrappers/CounterInternal';
 import '@ton/test-utils';
 import { compile } from '@ton/blueprint';
 
@@ -328,7 +327,6 @@ describe('HelloWorld', () => {
     let blockchain: Blockchain;
     let deployer: SandboxContract<TreasuryContract>;
     let helloWorld: SandboxContract<HelloWorld>;
-    let counterInternal: SandboxContract<CounterInternal>;
 
     beforeEach(async () => {
         blockchain = await Blockchain.create();
@@ -354,34 +352,16 @@ describe('HelloWorld', () => {
             deploy: true,
             success: true,
         });
-
-        counterInternal = blockchain.openContract(
-            await CounterInternal.fromInit(0n, helloWorld.address)
-        );
-
-        const deployResultCounter = await counterInternal.send(
-            deployer.getSender(), 
-            { value: toNano('1.00') }, 
-            null
-        );
-
-        expect(deployResultCounter.transactions).toHaveTransaction({
-            from: deployer.address,
-            to: counterInternal.address,
-            deploy: true,
-            success: true
-        });
     });
 
-    it('should send an external message and update counter', async () => {
-        const counterInternalValueBefore = await counterInternal.getCounter();
+    it('should receive external message and update counter', async () => {
         const [__, counterExtBefore] = await helloWorld.getCounters()
         const increase = 5;
 
         const result = await helloWorld.sendExternalIncrease({
             increaseBy: increase,
             value: toNano(0.05),
-            addr: counterInternal.address,
+            addr: deployer.address, // Using deployer address
             queryID: 0
         });
 
@@ -391,33 +371,22 @@ describe('HelloWorld', () => {
             success: true,
         });
 
-        expect(result.transactions).toHaveTransaction({
-            from: helloWorld.address,
-            to: counterInternal.address,
-            success: true,
-        });
-
-        const counterInternalValueAfter = await counterInternal.getCounter();
-
-        expect(counterInternalValueAfter).toBeGreaterThan(counterInternalValueBefore);
         const [_, counterExt] = await helloWorld.getCounters()
         expect(counterExtBefore + BigInt(increase)).toBe(counterExt);
     });
-
-    // ... previous tests
 });
 ```
 
-This test describes the common transaction flow of any `multi-contract` system:  
-1. Send an external message to toggle the smart contract logic from outside the blockchain.  
+{/*This test describes the common transaction flow of any `multi-contract` system:
+1. Send an external message to toggle the smart contract logic outside the blockchain.
 2. Trigger one or more internal messages to be sent to other contracts.  
 3. Upon receiving an internal message, change the contract state and repeat **step 2** if required.
 
 Since the resulting sequence of transactions might be overwhelming for understanding, it's a good practice to create a `sequence diagram` describing your system. Here is an example of our case:
 
 <div style={{marginBottom: '30px'}} align="center">
   <img src="/img/tutorials/quick-start/multi-contract.png" alt="Multi-contract scheme"/>
-</div>
+</div> */}
 
 Verify that all examples are correct by running the test script:
 
@@ -430,15 +399,14 @@ Expected output should look like this:
 ```bash
  PASS  tests/HelloWorld.spec.ts
   HelloWorld
-    ✓ should correctly initialize and return the initial data (446 ms)
-    ✓ should send an external message and update counter (209 ms)
-    ✓ should increase counter (298 ms)
+    ✓ should receive external message and update counter (251 ms)
 
 Test Suites: 1 passed, 1 total
-Tests:       3 passed, 3 total
+Tests:       1 passed, 1 total
 Snapshots:   0 total
-Time:        3.663 s, estimated 4 s
-Ran all test suites matching /HelloWorld/i.
+Time:        1.841 s, estimated 2 s
+Ran all test suites.
+
 ```
 
 <Feedback />

docs/v3/guidelines/quick-start/developing-smart-contracts/processing-messages.mdx renamed to docs/v3/guidelines/quick-start/developing-smart-contracts/func-tolk-folder/processing-messages.mdx

@@ -37,9 +37,9 @@ Let's examine the [Cell](/v3/concepts/dive-into-ton/ton-blockchain/cells-as-data
 
 TON Blockchain uses a data structure called **Cell** as the fundamental unit for storing data. Cells are the building blocks of smart contract data and have the following characteristics:
 
-- A Cell can store up to 1023 bits (approximately 128 bytes) of data
-- A Cell can reference up to 4 other Cells (children)
-- A Cell is immutable once created
+- A Cell can store up to 1023 bits (approximately 128 bytes) of data.
+- A Cell can reference up to 4 other Cells (children).
+- A Cell is immutable once created.
 
 You can think of a Cell as the following structure:
 
@@ -118,11 +118,11 @@ fun saveData() {
 Let's modify our example slightly by exploring another common storage management approach in smart contract development:
 
 Rather than initializing global variables, we'll:
-1. Pass storage members as parameters via `save_data(members...)`
-2. Retrieve them using `(members...) = get_data()`
-3. Move the global variables `ctx_id` and `ctx_counter` into method bodies
+1. Pass storage members as parameters via `save_data(members...)`.
+2. Retrieve them using `(members...) = get_data()`.
+3. Move the global variables `ctx_id` and `ctx_counter` into the method bodies.
 
-Also let's add an additional **256-bit integer** to our storage. The modified implementation should appear as follows:
+Also let's add an additional **256-bit integer** to our storage as `ctx_counter_ext` global variable. The modified implementation should appear as follows:
 
 <Tabs groupId="language">
 <TabItem value="FunC" label="FunC">
@@ -184,7 +184,7 @@ fun saveData(ctxID: int, ctxCounter: int, ctxCounterExt: int) {
 
 Remember to:
 1. Remove the global variables `ctx_id` and `ctx_counter`
-2. Update function usage by copying storage members locally as shown:
+2. Update the function usage by copying storage members locally as shown:
 
 <Tabs groupId="language">
 <TabItem value="FunC" label="FunC">

docs/v3/guidelines/quick-start/developing-smart-contracts/storage-and-get-methods.mdx renamed to docs/v3/guidelines/quick-start/developing-smart-contracts/func-tolk-folder/storage-and-get-methods.mdx

@@ -1,4 +1,5 @@
 import Feedback from "@site/src/components/Feedback";
+import Button from '@site/src/components/button'
 
 # Setup development environment
 
@@ -52,7 +53,7 @@ This will run an interactive script to create the project template. You can ente
 
 1. **Project name**: `Example`  
 2. **First contract name**: `HelloWorld`  
-3. **Project template**: A **simple counter contract** in `FunC` or `Tact`  
+3. **Project template**: a **simple counter contract** in `FunC`, `Tolk` or `Tact`
 
 Finally, change your current directory to the generated project template folder and install all required dependencies:
 
@@ -61,10 +62,35 @@ cd ./Example
 npm install
 ```
 
-### Step 4 (Optional): IDE and editor support
+### Step 4 (optional): IDE and editor support
 
 The TON community has developed plugins that provide syntax support for several IDEs and code editors. You can find them here: [Plugin List](https://docs.ton.org/v3/documentation/smart-contracts/getting-started/ide-plugins/).
 
 Also, consider installing plugins that support **JavaScript/TypeScript** tools for your preferred IDE or code editor, specifically `Jest`, for debugging smart contract tests.
 
+
+
+## Choose the programming language
+
+Now that your environment is set up choose a programming language to get started:
+
+- **FunC or Tolk**: estimated time to learn is 40 min for each.
+- **Tact**: estimated time to learn is XX min.
+
+
+<Button href="v3/guidelines/quick-start/developing-smart-contracts/func-tolk-folder/blueprint-sdk-overview" colorType="primary" sizeType={'sm'}>
+  Start with FunC or Tolk
+
+</Button>
+
+
+<Button href="v3/guidelines/quick-start/developing-smart-contracts/tact-folder/tact-blueprint-sdk-overview" colorType={'secondary'} sizeType={'sm'}>
+
+  Start with Tact
+
+</Button>
+
+
+
+
 <Feedback />

docs/v3/guidelines/quick-start/developing-smart-contracts/setup-environment.mdx

@@ -0,0 +1,104 @@
+import Feedback from "@site/src/components/Feedback";
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# Blueprint SDK overview
+
+> **Summary:** In the previous steps, we installed and configured all the tools required for TON smart contract development and created our first project template.
+
+Before we proceed to actual smart contract development, let's briefly describe the project structure and explain how to use the **`Blueprint SDK`**.
+
+## Project structure
+
+:::warning
+If you didn't choose the proposed names in the previous steps, source code file names and some of the in-code entities may differ.
+:::
+
+<Tabs groupId="language">
+  <TabItem value="FunC" label="FunC">
+    ```ls title="Project structure"
+    Example/
+    ├── contracts/           # Folder containing smart contracts code
+    │   ├── imports/         # Library imports for contracts
+    │   │   └── stdlib.fc    # Standard library for FunC
+    │   └── hello_world.fc   # Main contract file
+    ├── scripts/             # Deployment and on-chain interaction scripts
+    │   ├── deployHelloWorld.ts     # Script to deploy the contract
+    │   └── incrementHelloWorld.ts  # Script to interact with the contract
+    ├── tests/               # Test folder for local contract testing
+    │   └── HelloWorld.spec.ts      # Test specifications for the contract
+    └── wrappers/            # TypeScript wrappers for contract interaction
+    ├── HelloWorld.ts           # Wrapper class for smart contract
+    └── HelloWorld.compile.ts   # Script for contract compilation
+    ```
+  </TabItem>
+  <TabItem value="Tolk" label="Tolk">
+    ```ls title="Project structure"
+    Example/
+    ├── contracts/           # Folder containing smart contracts code
+    │   └── hello_world.tolk # Main contract file
+    ├── scripts/             # Deployment and on-chain interaction scripts
+    │   ├── deployHelloWorld.ts     # Script to deploy the contract
+    │   └── incrementHelloWorld.ts  # Script to interact with the contract
+    ├── tests/               # Test fo der for local contract testing
+    │   └── HelloWorld.spec.ts      # Test specifications for the contract
+    └── wrappers/            # TypeScript wrappers for contract interaction
+    ├── HelloWorld.ts           # Wrapper class for smart contract
+    └── HelloWorld.compile.ts   # Script for contract compilation
+    ```
+  </TabItem>
+</Tabs>
+
+### `/contracts`
+
+This folder contains your smart contract source code written in one of the available programming languages used for TON Blockchain smart contract development.
+
+### `/wrappers`
+
+To interact with your smart contract off-chain, you need to serialize and deserialize messages sent to it. `Wrapper` classes are developed to mirror your smart contract implementation, making its functionality simple to use.
+
+### `/tests`
+
+This directory contains test files for your smart contracts. Testing contracts directly on the TON network is not the best option because deployment requires some amount of time and may lead to losing funds. This testing playground allows you to execute multiple smart contracts and even send messages between them in your **"local network"**. Tests are crucial for ensuring your smart contracts behave as expected before deployment to the network.
+
+### `/scripts`
+
+The `scripts` directory contains `TypeScript` files that help you deploy and interact with your smart contracts on-chain using previously implemented wrappers.
+
+## Development flow
+
+Almost any smart contract project development consists of five simple steps:
+
+1. Edit the smart contract code in the `/contracts` folder and build it by running the build script:
+
+```bash
+npx blueprint build
+```
+
+2. Update the smart contract wrapper in the `/wrappers` folder to correspond to changes in the contract.
+
+3. Update tests in the `/tests` folder to ensure the correctness of the new functionality and run the test script:
+
+```bash
+npx blueprint test
+```
+
+4. Repeat steps 1-3 until you achieve the desired result.
+
+5. Update the deployment script in the `/scripts` folder and run it using this command:
+
+```bash
+npx blueprint run
+```
+
+:::tip
+All examples in this guide follow the sequence of these **1-3 steps** with corresponding code samples. **Step 5**, the deployment process, is covered in the last section of the guide: [Deploying to network](/v3/guidelines/quick-start/developing-smart-contracts/deploying-to-network/).
+:::
+
+Also, you can always generate the same structure for another smart contract if, for example, you want to create multiple contracts interacting with each other by using the following command:
+
+```bash
+npx blueprint create PascalCase # Don't forget to name the contract in PascalCase
+```
+
+<Feedback />