_isInherited - usage?

[tomallpress]

I'm not clear on use cases for the _isInherited json attribute. I think I understand what it's doing (inheriting the parent's trickle configuration and putting it on the child element. But I'm not clear in what scenarios this needs to be controlled?

If you're setting all of the configurable elements at article level, then using the blocks to override some of those properties (for example not having the button enabled within one of the blocks), what's the need to explicitly say if a block is inheriting the parent articles trickle config? it either does inherit the parent config, or you put overrides on blocks for specific trickle settings. In which case I personally would be assuming it's inheriting everything from the parent, with the exception of anything I'm overriding on the block.

The way it's currently behaving, it looks like any overrides at block level are ignored if _isInherited is set to true on the block. Is this expected? if so, again, I'm not entirely sure what the purpose of it is.. because you're defining those settings at article level, with any blocks within that article inheriting those configs anyway... so what's the purpose of having to explicitly state on blocks with overrides, that that specific block is not inheriting everything from the parent article?

I'm probably missing something as to it's desired usage... if I am, could more information be added to the readme for what _isInherited does/how it can be used please?

[oliverfoster]

I understand your workflow when building a course by hand, _isInherited seems unnecessary as the block config is excluded when not used.

Could you please check how the AAT outputs the config. It used to be that all of the block config came out on all of the blocks, regardless of whether you'd changed anything. This meant that a human had to signify if the block config was indeed important and applicable with _isInherited.