Mixins in Riot.js

Ray Viljoen
A free video tutorial from Ray Viljoen
Practical Courses Designed for Learning Efficiency.
4.7 instructor rating • 7 courses • 57,669 students

Lecture description

Learn how to share functionality across your Riot tags with powerful mixins.

Learn more from the full course

Master Riot v3: Learn Riot.js from Scratch

Go from zero to Master with the React-inspired, Riot.js library. A powerful, yet flexible, javascript view layer.

03:15:03 of on-demand video • Updated May 2020

  • Create customised Riot implementations specific to the project they are working on.
  • Understand, in depth, each individual aspect of the Riot API.
  • Have the know-how to implement Riot in practical ways to build rich, real-world web applications.
  • Know how to use Riot both client-side & server-side.
  • Implement dynamic HTML5 routing, using the built-in Riot router.
  • Write more logical & modular Javascript via simple Riot design principles.
English [Auto] Mix ins is a way for Riot acts to share common functionality. So a more conventional way of thinking about them would be similar to inheritance only in a much simpler way. I'll start by creating a new tag file. Just call it CTA or click through action create the opening and closing tax and add a button remove some of the attributes and will set the name via the options object. So we'll have to define it on the CTA tag implementation and the same for the button text options doc label. Then implement that CGI tag on the index file. Just replace the Hello World Tag assign it a name say CTA a button and set the button text. Click here for that label attribute and link to that tag by replacing the hello world script save and we get that button. Now there's three ways of implementing mixdowns. The first being locally on a single tag so add a script tag and define the mixin object on the tag that will be adding the mixin. I'll call this required option. Make that an object and add a method called check option. Pass a variable called option t and say if Boltz the start options BT then log an error to the console saying missing option and the option variable. This should be fairly clear. But what this method does is simply take the string argument that gets passed to it and check it on the current tag instances options to see if it exists. It's important to understand that when a mixin gets added to a tag it becomes part of that instance and why we can access the tags instance fire. This in the mix in then to actually add the mix into the CTA. We can say this doc makes in and pass them acts and object and this now allows us to use the method on that mixin as part of our tag instance. Say this doc check option and will check for. Name save that and everything is fine as the name auction is set. If however I jump over to the implementation and remove the name attribute save we see that error being locked in the console missing option name another neat feature of mixin. Again much like Klaas's is that we can define an innate method that will run as soon as the tag is mounted. I'll change this check option method to init remove the variable and check explicitly for that name option. And get rid of this check options method. Save of course nothing as the name option is set. So over to the index file. Remove that name option again save. And we get the error in the control again. We can also do something like this stop on Mount and log required option mixin. Add it to the start root not local name which is the name of the tag. This tag instance belongs to save that and we see required option mixin added to CTA. This is great but I've found that I pretty much never use mixing locally like this. Instead we can use a shared mixing which is the second method of adding a mixing I'll cut this mix in from the tag added to the index file. We could of course have added this to its own javascript file as well and simply link to it and then we can register this mixin by saying ryot talk mix in give it a name. I'll just stick to requite option and pass the mixing object. This is now what's called a shared mixin so it's available to all tags but still needs to be added to them explicitly. Which we do in the same way as before. Save the CTA tag and we still get that same lock message from the init method. And if I comment this out nothing. So to me this is the most practical implementation as it allows us to share mixin across our. But still gives the developer control over where to implement them. The third and final way of using Maxine's is what's referred to as a global mixin. All we need to change to do this is remove the mixin name so simply ryot don't mix in and pass the mixin object save. And interestingly we get that log message twice in the console. That's because global mocassins automatically gets added to all tags and then we still have that explicit call to add to the mix in our tag as well. I'll just get rid of that save and now we get the expected behavior.