Wix Blocks provides various code file types for efficient app development. Public files handle client-side logic, while backend files manage server-side operations and database interactions. Web modules offer reusable backend code snippets. Additionally, a configuration file stores app-wide settings.
In addition to these core code files, widget, panel, and dashboard code are essential for building the user interface and app management features.
Adding code files for the first time requires releasing a major version.
Where you add code files depends on the tool you are using.
In the Blocks editor:
In the the Blocks-CLI integration, add code files directly from your IDE.
In the Wix IDE for Blocks, add code files in the Wix IDE.
Blocks public files are JavaScript files, or TypeScript files when working with the Blocks-CLI integration. These files have exported functions that can be imported and called in your app or on a website where the app is installed.
Blocks backend files are used to manage server-side operations and database interactions. These files are not directly accessible from the frontend, ensuring that sensitive operations and data handling are securely managed on the server side. There are several types of backend files you can add to your app:
.js
files: are not directly accessible to users via front-end code..web.js
files: are accessible to the frontend. Use these to import functions from the backend into files or scripts in page code or in public files, and the functions will run on the server. Wix handles the client-server communication. Learn more about calling backend code from the frontend..jws
files: were used in the past instead of web.js
. Currently deprecated but supported.events.js
and http-functions.js
files.data.js
, routers.js
, realtime-permissions.js
.You can test backend functions in your app without releasing or installing the app.
Every exported function at the root of a public or backend directory will be exposed when installing your app on a site. Note that exported functions that aren't in the root package will not be exposed.
Make sure to give your functions unique names. Blocks cannot expose two functions under the same name within the same app.
A Blocks config.json
file to defines settings that impact how your app works on a specific site. These settings typically vary from site to site, so the file you provide contains default settings that users can edit for each site.
When a user installs your app on their site, they can modify the values in configuration file through the Packages & Apps tab in the editor, for example:
The data in the config.json
file can only be imported by backend files.
Examples of information you might put in a config.json
file include:
We recommend that your README.md
file contains instructions for modifying the config.json
file.
config.json
settingsThe values in config.json
can only be accessed by the backend code in your app.
Import the config.json
file, using getPackageConfig:
Use the values from the file in your backend code:
config.json
examplesIn Tutorial: Creating a Package for API Calls, you create a config.json file that contains a default stock symbol to use in a stock quote API call. You can edit that value on any of your sites on which you've installed the API Call package.
The config.json
file:
The tutorial's backend apiCall.jsw
file imports that value and uses it in the code as the value for the stock symbol variable, sym.
You can add npm
dependencies to your app.
To add an npm
package:
Learn more about installing npm packages.
Add a README.md
Markdown file to document your app. Your README should include the following sections:
npm
packages, included in your app, along with licensing information for those packages. For example, your users should be aware that when they install a package that uses an npm
package, they agree to that package's license agreement.