When we work with Episerver blocks you may have heard of 'shared' blocks and 'local' blocks. In today's guide, I'm going to discuss the differences between them and go over the code required for each.
Shared Blocks... Local Blocks... Why is this So Complicated?!?!
The good news is that there's no real difference between a shared block and a local block. The code for the block is exactly the same, so you don't need to worry about learning anything new!
The difference between shared/local is how the block is called. If you 'hardcode' a block as a property on a page or block, then it is considered a local block and is only available to that page block. A shared block, on the other hand, is created when a content editor adds a block in the editor via a content area. When this happens a block is created in the shared block folder and it can be used in other areas of the site. It really is pretty simple. Just to prove it, I'm going to walk you through the code to create a local block. Given this block:
To create a local block, we would add it to a page/block like this:
That's it, you've now created a local block. For simplicity, I'll go over the code to create a share block on a page. You simply add this:
Why Use Local Blocks?
Local blocks are a great way to lump related functionality together. Usually, on a project, you'll have a requirement to create pages/blocks where a content editor can add an image or a link.
Lets pretend we need to add several images to different pages and blocks. One way of doing this is to add a URL property and an alt tag property on each page/block where needed, like so:
Using this approach is a bit sub-optimal.
First, it means anywhere you need to hand type these properties everywhere it's needed, which breaks the DRP principle of development.
Second, as you're handwriting these properties it is highly likely you'll accidentally give the name/descriptions different terms, meaning the editor experience differs slightly.
Third, adding properties doesn't group things nicely in the editor. Instead, creating a local block to deal with images would be a better solution. The code for the block would look like this:
The image block as local blocks on a page would look like this:
Now we have an image block, we have a quick and standardized way of adding an image to a block/page. As the properties are definitely in one class we have standardized naming conventions throughout the project and if you look in the editor, the image properties will be group together, making it easier for content editors to figure out how a block works.
Why Use Local Blocks?
When making a modern website, an image might need a desktop image, a mobile image and an alt tag. Create a local block to cater for this repeated functionality will mean you'll write less code, you'll standardise the naming within the editor and you'll have less unit tests to write.
When you use a local block, you will still need to add the 'ContentType' attribute to the class. Also, when you create local blocks the sole purpose is to wrap functionality. In most instance you won't want the block appearing as a selectable thing to an editor.
In most instances, you simply want them to appear on the page/block that you specify. To hide a block from an editor, add the AvailableInEditMode = false property, like so: