Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://cloudinary.com/documentation/javascript1_migration_guide below:

JavaScript Migration Guide | Documentation

Cloudinary's latest JavaScript SDK is designed to provide a simpler and more enhanced developer experience than the legacy JavaScript SDK. This guide explains how to migrate your JavaScript code from the cloudinary-core library (legacy JavaScript SDK) to the js-url-gen library.

Key improvements in the js-url-gen library:

• A new action-based syntax, designed to make building delivery URLs and transformations more logical and discoverable.
  • When compiled to the final delivery URL, each action (including any action qualifiers) represents a different component (separated by a '/'), for example: /c_scale,w_400/f_auto/q_auto/, rather than /c_scale,f_auto,q_auto,w_400/.
• Newly added autocomplete to list options and parameters and ensure only those that are supported can be used together.
• A smaller bundle size - you only need to import what you want to use.

Things to know before migrating to the js-url-gen library

The action-based syntax used in the js-url-gen library may cause URLs to be formed differently from those generated by the cloudinary-core (legacy) library.

For example:

• URL generated with the cloudinary-core (legacy) library:
  https://res.cloudinary.com/demo/image/upload/c_scale,f_auto,q_auto,w_400/sample.jpg
• URL generated with the js-url-gen library:
  https://res.cloudinary.com/demo/image/upload/c_scale,w_400/f_auto/q_auto/sample.jpg

Even if the delivered media file looks and behaves identically, changes to URLs can have the following implications:

• You may see a one-time increase in transformation counts
• You may see a one-time increase in storage usage for the new derived assets
• You may see a one-time increase in add-on usage when add-on transformation parameters are used in the URL
• CDN caches may need to be warmed with the new derived assets
• If strict transformations are enabled for your product environment (in the Security page of your Console Settings), you need to allow the new transformations
• If you require transformations to be generated eagerly, for example long videos, you need to regenerate these via the latest SDK, using the eager parameter of the explicit method.

To reduce the impact of all of the above, we recommend using the createCloudinaryLegacyURL method for your existing transformation URLs, especially if your existing app delivers a large number of transformed assets. This maintains the formations of the transformations, so the URLs remain the same.

The createCloudinaryLegacyURL function supports only transformation and configuration parameters. It does not help to migrate HTML tags, responsive, placeholder, transparent video or jQuery functionality.

For all new transformation URLs that you add to your application, we recommend using the new action-based SDK syntax offered by the latest version of the SDK.

For full documentation on using the js-url-gen library, see the JavaScript SDK guide.

The cloudinary-core library is very different from the @cloudinary/url-gen library in its architecture and usage, so migration paths depend on your current usage of the cloudinary-core library.

You can use both the cloudinary-core and @cloudinary/url-gen packages in your application concurrently, so although not recommended for the long term due to the increased bundle size, you could start by integrating @cloudinary/url-gen into your application and slowly migrate your functionality piece by piece, until you are able to remove all cloudinary-core functionality.

The instructions in this guide assume you are using JavaScript within a modular environment.

Install the @cloudinary/url-gen package using:

Using the legacy JavaScript SDK, you may be configuring your cloud name and other configuration parameters in a Cloudinary instance. There is an equivalent Cloudinary object in @cloudinary/url-gen.

For example, this cloudinary-core code:

is similar to this @cloudinary/url-gen code:

You can also set configuration parameters in the imageTag or url methods in the JavaScript SDK v1. This is similar to setting the parameters on a per asset instance in @cloudinary/url-gen.

For example, setting cloud_name in a URL:

is similar to setting cloudName in a CloudinaryImage:

Using cloudinary-core, configuration and transformation parameters are specified in JSON syntax, for example:

Using @cloudinary/url-gen, you can use the createCloudinaryLegacyURL function to pass in the same JSON and return the same URL, which you can then use as the source for your image tag. Configuration parameters, such as cloud_name, should be included in the function call as this is simply a helper function to build the delivery URL.

For objects, such as Layer(), TextLayer(), FetchLayer() and Transformation(), you need to import the relevant classes from @cloudinary/url-gen/backwards.

If you have a large number of assets, we recommend you migrate using the

method. If you replace your existing transformations using the new SDK transformation syntax, you may find your URLs are generated in a slightly different way. See

, for the implications of these changes to transformation URLs.

For all new Cloudinary delivery URLs, you should start to use the @cloudinary/url-gen syntax, which, for the above example, is:

The resulting URL is:

If you are using the responsive functionality offered in cloudinary-core, you will have to replace this code entirely when using the latest JavaScript SDK.

For this, you need to install the @cloudinary/html package from frontend-frameworks:

Then, use the responsive plugin in an HTMLImageLayer:

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4