In today's guide, I'm going to discuss the differences between Episerver 'shared' blocks and 'local' blocks. You will learn the differences between them and when you should use each type. I will go over the code required for creating each one so you can get a good understanding of what they do and why.

Shared Blocks... Local Blocks...

The good news is that there's no real difference between a shared block and a local block codewise. The code required to create both types of the block is exactly the same. You don't need to worry about learning anything new! The difference between shared blocks and local blocks is how they are used rather than how they are built. 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 type. A shared block, on the other hand, is created when a content editor adds a block within a content area in the editor. When blocks are added into content areas, they are also linked from the shared block folder. From this folder, the block can be linked to other areas in 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 the code snippet to create this block:

To create a local block, we would decorate it onto a page/block definition 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 a content area onto a page and allow that block to be added inside of it:

Here we define aContentArea rather than hard-coding the block!

Why Use Local Blocks?

Local blocks are a great way to group related data types together. For example, on most projects, you will have a requirement to create a property that will allow a content editor can add an image or a link onto a page. Let us pretend we need to add several images around the site on different pages and blocks. One way of doing this is to add a URL property and an alt tag property on each page/block wherever an image is needed, like so:

Having to duplicate this code all over your codebase like his is sub-optimal. First, it breaks the DRP principle of development. Second, as you're duplicating properties it is highly likely you'll accidentally use different name and descriptions throughout the project, meaning the editor experience differs slightly. Finally, adding properties doesn't group things nicely in the editor.

Instead of using this ad-hoc approach to define properties when needed, creating a local block to deal with images would be a better solution. The code for the image block would look like this:

To use this 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 on any block or page within the project. As the properties are defined in one place, we have standardized naming conventions throughout the project. If you look in the editor, the image properties will be group together, making it easier for content editors to use the CMS, nice 💥💥💥

When making a modern website, an image might need a desktop image, a mobile image and an alt tag. Creating a local image 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 fewer unit tests to write.

When you use a local block, you will still need to add the ContentType attribute onto the class. 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 block within the create new block screen within the editor. To hide a block from an editor, add the AvailableInEditMode = false property, like so:

You are now a local block Jedi, happy Coding 🤘