Wix Velo Revision Q/A

In this tutorial I will be providing a revision on some topics, questions and concepts that are required to be known for you to pass and earn the velo certification by wix.

Learn more about certification

The following are some of the multiple choice questions that you will come across.

---

Question 1:

Which of the following is correct regarding a dynamic wix dataset? Select all answers that apply.

A - its mode will never be write only

B - it allows switching between multiple collections

C - its data is retrieved based on the URL of the page

D - its position in the page will change dynamically

The correct answer is A and B. Here is why.

When considering the properties and behaviors of a dynamic Wix dataset, here's an analysis of the statements you've provided:

1. Its mode will never be write-only - Correct. Wix datasets can be set to either read-only, read-write, or write-only mode. However, a dynamic dataset, which automatically populates its content based on the context of the page (like from a URL parameter), typically needs to either display (read) or modify and display (read-write) data. A write-only mode wouldn't be practical for a dynamic dataset because it needs to show data based on context.

2. It allows switching between multiple collections - Incorrect. A Wix dataset is tied to a specific collection. If you need to work with multiple collections, you would need multiple datasets or to programmatically manage these connections in your code, but a single dynamic dataset cannot be set to switch between multiple collections by itself.

3. Its data is retrieved based on the URL of the page - Correct. A dynamic dataset can indeed retrieve data based on the URL of the page. For example, it can use URL parameters to filter data, which is a common approach in creating dynamic pages on Wix where the dataset's content is determined by parameters passed via URL.

4. Its position in the page will change dynamically - Incorrect. The physical position of a dataset in the Wix Editor does not change dynamically; it's a non-visual element that manages data behind the scenes. Visual changes or the placement of elements that the dataset is connected to are managed separately through design or through specific interactive or responsive behaviors in the editor or via code.

From the options provided, the statements that the dynamic dataset's mode will never be write-only and its data can be retrieved based on the URL of the page are correct.

---

Question 2:

select the correct statement for the following question. What is the difference between .jsw and .js backend files?

A - Only JS files can be imported using the Job Scheduler.

B - Only JSW files can be exported as an http-function.

C - Only JSW files can be imported in the frontend code.

D - Only JSW files can interact with the collection data through the backend section of your site.

The correct answer is C. Here is why.

From the options provided, the correct statement that accurately describes the difference between .jsw and .js backend files in the context of Velo by Wix is:

• Only JSW files can be imported in the frontend code.

Explanation:

• Only JSW files can be imported in the frontend code: This is correct because .jsw files, or web modules, are designed to allow functions within them to be exposed to the frontend. This allows for server-side functionality to be safely called from client-side code, which is essential for executing server-side logic without exposing sensitive operations directly to the client.

Incorrect Options:

• Only JS files can be imported using the Job Scheduler: This statement is incorrect. Job Scheduler in Wix can be used to schedule jobs that can invoke functions from both .jsw files and .js files, as long as they are exposed properly for such operations.

• Only JSW files can be exported as an http-function: This statement is incorrect. .jsw files are not used for creating HTTP functions; rather, .js backend files are used for this purpose, enabling them to handle direct HTTP requests like APIs.

• Only JSW files can interact with the collection data through the backend section of your site: This statement is misleading. Both .jsw and .js backend files can interact with database collections on Wix. The main difference lies in how they are accessed and used (.jsw for server-side functions callable from the frontend, and .js mainly for HTTP APIs).

Thus, the statement that only .jsw files can be imported in the frontend code is the correct choice among the options given.

---

Question 3:

select the correct statement for the following question. What do backend functions in web modules return when called from the frontend?

A - A Promise

B - Backend functions cannot return a value to the frontend.

C - JSON

D - Whatever value the backend function returns.

The correct answer is A, here is why.

The correct statement regarding what backend functions in web modules return when called from the frontend in Velo by Wix is:

• A Promise

Explanation:

• A Promise: When a backend function from a .jsw file (web module) is called from the frontend in Velo by Wix, it returns a Promise. This Promise will eventually resolve to the value that the backend function returns. This mechanism is necessary because the call is asynchronous, allowing the frontend to continue processing other tasks while waiting for the backend function to complete and provide a result.

Why Other Options Are Incorrect:

• Backend functions cannot return a value to the frontend: This is incorrect as backend functions can indeed return values to the frontend. They do this by resolving the returned Promise with the value.

• JSON: This is misleading. While it's true that many backend functions might serialize their return values as JSON, especially when dealing with HTTP requests directly, in the context of web modules, the data passed back to the frontend is automatically serialized and deserialized by the Velo platform, regardless of whether it's explicitly formatted as JSON in the code.

• Whatever value the backend function returns: This is partially correct in a broad sense but doesn't encapsulate the asynchronous nature of the interaction, which is fundamental to understanding how data is returned from server-side to client-side in a web application. The precise mechanism involves Promises, which handle the asynchronous operation.

Thus, stating that a backend function returns a Promise when called from the frontend is the most accurate and complete explanation for Velo by Wix web modules.

---

Question 4:

Which of the following uses of $w is NOT valid?

A - $w('Button')

B - $w('.itemClass')

C - $w('#itemID1, #itemID2, #itemIDt3')

D - $w('#itemID')

The correct answer is A, Here is why.

In the context of Velo by Wix, $w is used to select elements on a page in order to manipulate them or attach event listeners, among other operations. The $w selector is similar to jQuery's $ selector but specific to Wix's development platform. Here’s a breakdown of each of the provided selections to determine their validity:

1. $w('Button')

• Assessment: This use is not valid. $w expects a selector that begins with a # for IDs or . for classes, or it uses a specific API to select elements by type, such as $w('Button') to select all buttons. However, Velo by Wix does not support selecting elements by their type without specific identifiers or qualifiers.

1. $w('.itemClass')

• Assessment: This use is valid. $w can select elements by their class name, which is indicated by the prefix ..

1. $w('#itemID1, #itemID2, #itemIDt3')

• Assessment: This use is not valid. While CSS and jQuery support selecting multiple IDs using a comma-separated list, $w in Velo by Wix does not support multiple ID selectors in a single string. Each ID needs to be targeted with its own $w() function call.

1. $w('#itemID')

• Assessment: This use is valid. This is the standard way of selecting an element by its ID in Velo by Wix, where the # indicates an ID selector.

Based on this analysis, the uses of $w('Button') and $w('#itemID1, #itemID2, #itemIDt3') are not valid, with $w('Button') being particularly incorrect given your question about which one use is not valid. This is because Velo by Wix doesn't support selecting elements merely by their type without any additional specificity or context.

---

Question 5:

How do you send a POST request using wix-fetch?

A - Define POST as the method in the fetch options.

B - No need to. POST is already the default method when using wix-fetch.

C - wix-fetch is only for GET requests.

D - You need to use wix-send instead. Use wix-fetch in the backend, and then it defaults to POST.

The correct answer is A, Here is why.

To send a POST request using wix-fetch on the Wix platform, you must explicitly define POST as the method in the options of the fetch() function. This is necessary because the default method for fetch() (both in standard JavaScript and in wix-fetch) is GET. Here's the correct approach:

• Define POST as the method in the fetch options.

This is how you properly specify that your request should use the POST method when using wix-fetch

Analysis of Other Options:

• No need to. POST is already the default method when using wix-fetch.

• This is incorrect. As mentioned, the default method for HTTP requests using fetch() is GET, not POST.

• wix-fetch is only for GET requests. You need to use wix-send instead.

• This is incorrect. wix-fetch can be used for all types of HTTP methods, including POST, GET, PUT, DELETE, etc. There is no wix-send; fetch is the standard method used for making HTTP requests.

• Use wix-fetch in the backend, and then it defaults to POST.

• This is incorrect. Whether used in the backend or frontend, wix-fetch does not default to POST. You always need to explicitly set the method to POST if that's what your request requires.

Thus, to properly send a POST request in Wix using wix-fetch, you must define POST as the method in your fetch options.