This actually shows that you don’t understand how native custom elements works.
It’s an easy fix, you only need to add the script once globally in the page 
Edit: it’s in part also a limitation of the library imported because it doesn’t check if the component is already declared.
Of course it’s an easy fix, just not strictly necessary for it to function. I’ll add it to the solution though if people want to do it!
A solution that introduces an error is not a complete solution.
This post is aimed at people beginning with bubble, so of course they can’t understand the error. If you leave them with something that throws an error it’s the same as having a bad plugin.
You can check if the element is defined, but you can’t know if another library used your namespace, so I get why this library want the behavioiur that throws, so that the dev knows that the library bust be loaded only once.
You’re right, which is why I’ve added the extra info to the solution 
EDIT:
renamed thread
To respond to some of the issues highlighted above:
This thread will remain a thread to post free/native solutions to paid plugins
The solutions won’t be posted on the original plug-in’s page. I can see why that annoyed some people. I’ll just hope the buyer finds this thread during their search. I’ve taken your concerns on board 
This thread isn’t telling anyone what to do - it’s not being dishonest or just slander - it’s giving actionable information so that any Bubbler can make an educated purchase decision. I’ve now made it explicitly clear this post isn’t authoritative at the top of the post.
If anyone noticed any issues with solutions I’ve written or linked let me know so they can be fixed
There’s nothing wrong with publicising free solutions to plugins that have no business being paid plugins. I would’ve said plugins’ topics are fair game as it is a public forum and is relevant but after listening to everyone I’ll keep it all here. Right idea, bad execution first time round But this thread is here to stay.
Taking this a step further…
What I do in my apps is I create an option set that I call Option-lottie-files (I always put the word option in front of my option sets to easily distinguish them from data types). I add an attribute called URL as a type text. This URL is all you really need to have different lottie files available. It is the Asset Link.
Then I create a reusable element that I call lottie file. It can be of type group or popup (I primarily make all my reusable elements a group and then on the page where I use them place them in a popup or a floating group if I want to use them that way on that page; this gives more flexibility to how you use and display the reusable element. I only really set a reusable to a popup when it is a warning popup which would in my case only ever be used as a popup).
In the reusable I have a content type set to the option set I created called Option-Lottie-File. I add an HTML element to the reusable as below
Doing it like this, as a reusable element where the script is in the reusable element and the HTML is dynamic when the asset link is referenced dynamically via the option set attribute eliminates the issue of loading the same script multiple times on the page when you might have more than one lottie file needed on the page (keep in mind, you wouldn’t be showing more than one lottie file at a time, if you were, then likely you’d want to have the script directly on the page).
Then I can place the reusable element on any page I want to use it, or into another reusable element like the header. Then when I want to display the lottie file, I can set the option set to indicate which lottie file to display. I use this for things like payments. I show one lottie file during the processing of the payment, and a different lottie file once payment is successful, and all I need to do is either display the option set to the reusable through a workflow action to change from the payment processing to the payment complete, or on the reusable element itself, conditionally change the source of the reusable from the payment processing to the payment complete.
For me, this setup reduces the number of elements I would need to create throughout my app, as I am using a reusable element, and makes managing all my lottie files easier as they are all in one place through use of the option set.
If you wanted to go further, you could also dynamically change the width and height of the lottie file, but that is not really recommended unless you are changing the width and height according to the lottie files original dimensions ration (this is because when creating the lottie file or using a pre-existing one, the width and height are already set, and changing them without keeping the same aspect ratios will distort the lottie file display.
You can go further still and add to the lottie file option set another attribute of the speed to playback or the duration of the lottie file and match them to the duration in which you display the lottie file. For example, if my lottie file is setup to show a rocket ship blast off and the lottie file duration is 2.5 seconds, I don’t want my setup to automatically close the lottie file after just 1.2 seconds and my rocket ship has not yet blasted off, so I could use the additional attribute in the option set to match the duration of which the lottie file is visible to the user so they get the full experience of the animation.
I really like using lottie files for more than just loading screens. They are a great way to also create fun ‘processing’ screens, or even animated graphics that are always visible on the page (I use one on my 404 pages).
Thanks for sharing your tip on lottie file usage as a loading screen.
Neat idea! Added this post to the solution links
Following the actual documentation you can use <script src="https://unpkg.com/@dotlottie/player-component@latest/dist/dotlottie-player.mjs" type="module"></script> to import the library. This way the library’s code is executed only once, even if it’s referenced multiple times (source)
