Next.js Image Component with Cloudinary (Next.js 12 and below) - Dev Hints
Next.js Image Component with Cloudinary (Next.js 12 and below) - Dev Hints
Get the best of Cloudinary while using the Next.js Image Component. Learn how to add Cloudinary URLs to the list of allowed domains for the Image component and use the built-in Next.js Cloudinary loader to take advantage of more Cloudinary features.
⚠️ Update: Next Cloudinary now available for a full-featured Cloudinary integration in Next.js
https://next-cloudinary.spacejelly.dev/
Or learn how with: • Automatic Image Optimization \u0026 Dynami…
🚨 Warning: Next.js 13 deprecated global loaders which prevents this method from working. Try Next Cloudinary for a full-featured integration using the link above or use one of the code examples below to see how to integrate with Next.js 13.
💾 Using Cloudinary URLs
https://github.com/colbyfayock/cloudi…
💾 Using the Cloudinary Loader
https://github.com/colbyfayock/cloudi…
Instructor: Colby Fayock ( @colbyfayock )
—
Cloudinary helps developers build performant experiences for the web with powerful optimization and transformation APIs.
🚀 Get started with a free account!
https://cld.media/devhintsnextimage
#cloudinary #devhints #nextjs #images #webdevelopment
Content
5.22 -> when using next.js we can take advantage
7.68 -> of all the components and tools they get
9.48 -> us out of the box like the next JS image
11.94 -> component that has cloudinary support
13.44 -> built right in allowing us to both use
16.02 -> the features of the image component like
17.64 -> layouting and responsiveness while using
19.859 -> the power of cloudnary so after you
22.08 -> import your image from next image we can
25.56 -> simply swap our existing image tag with
27.96 -> the image component the only issue is by
30.48 -> default that doesn't work because we
32.16 -> need to make sure that we add any domain
34.38 -> we're trying to load an image from to
36.3 -> our allowed list so to fix this inside
38.82 -> of our next dot config.js file we can
41.64 -> add a new property of images we're
43.98 -> inside we want to also add a property of
46.379 -> domains which is going to be an array
48.6 -> where we're going to add res dot
50.78 -> cloudenary.com or wherever the domain is
53.579 -> that we're serving our images from now
55.62 -> because we made a file to our
57.26 -> next.config.js file we need to make sure
59.219 -> we restart our development server where
61.44 -> once it reloads we can see all of our
63 -> images load right in the browser if we
65.64 -> look in the web inspector we can see
67.08 -> that the images are now being served
68.52 -> from slash next slash image with that
70.56 -> URL which is the next.js mechanism in
73.56 -> order to provide all those benefits
75.6 -> but what if we wanted to serve our
76.92 -> images directly from cloneary and take
79.08 -> advantage of some of the same features
80.64 -> of the image component only baked into
82.86 -> our cloudner URL we can instead take
85.5 -> advantage of the loader's functionality
87.18 -> where we can take advantage of the
88.56 -> built-in cloudinary loader now to do
90.9 -> that inside of our next.config.js the
93.299 -> first thing we're going to do is replace
94.56 -> our images domains key with a loader and
97.259 -> we're going to set that to cloudnary we
99.42 -> then want to set the path which is going
101.159 -> to be our cloudinary address which
103.259 -> includes the domain and our Cloud name
105.119 -> where then we can specify our cloudinary
107.64 -> address which by default is
109.34 -> res.cloudnery.com or whatever your
111.659 -> custom domain is and then I'm going to
113.399 -> include my cloud name which in my
115.02 -> instance is Colby Cloud examples but
116.939 -> make sure to use your Cloud name here we
119.399 -> also want to make sure we include the
121.079 -> asset type of image as well as the
123.479 -> delivery type of upload but then
125.82 -> anywhere that we're referencing our
127.619 -> cloudery URL images we want to make sure
129.84 -> we remove that part of the address from
132.48 -> each of those URLs so if we can see here
134.7 -> I have my res cloudery.com with my cloud
137.7 -> name the image asset type and the
139.739 -> delivery type I'm going to select all
141.78 -> the images that include that and I'm
143.64 -> going to remove that beginning segment
145.98 -> now as usual because we made a change to
148.14 -> our next config we want to make sure we
149.76 -> restart our development server
151.62 -> but now once we reload the page we can
153.48 -> see all of our images loading inside of
155.28 -> the browser and if we actually inspect
156.959 -> it we can see that they're loading from
158.94 -> a cloudinary source where we can even
160.739 -> see if we look closely that it has the
162.66 -> URL parameters like a traditional
164.7 -> clowner URL where we have our format of
167.16 -> Auto for modern formats our queue of
169.739 -> Auto for automatic quality compression
171.599 -> as well as any of the other parameters
173.519 -> that nexjs is using with that loader
175.92 -> component so in review we have multiple
178.14 -> ways of how we can take advantage of
179.64 -> cloudinary in an xjs application whether
181.92 -> that's simply adding it to the allowed
183.72 -> domains for the next component or if we
186.12 -> want to actually set up the cloudery
187.5 -> loader so we can take advantage of all
189.42 -> the different cloudinary features
191.34 -> while still taking advantage of the
193.019 -> cloudinary experience that you would
194.34 -> expect
Source: https://www.youtube.com/watch?v=twkImfEsnAs