Skip to main content

In the component pack tutorial, there are some properties for Component Definition that I’m hopeful someone can provide some additional background on.

alwaysLoad - This indicates that dependencies of a component will be loaded even if the component isn’t requested.  Questions:

  1. Does this mean that even if a page does not contain a component from the pack, that the component runtime, css, etc. will be loaded in to any skuid page in that org?

  2. Beyond customLabels, js & css, is there anything else that is considered a depdendency? 

pathsToChildComponents - This indicates that skuid will check for child components and process their logic.  Questions:
  1. When/How should this be used?  When the custom component itself contains things like basicfieldeditor, skootable, etc.?

  2. What is the expected value that should be set for this property?  Given it’s name, it would appear to be a string (path) property (possibly even an array of strings) but the way the description reads (“Property that specifies if this component…”) it could be a boolean?

Thank you!

alwaysLoad
1. If a Component is marked as alwaysLoad, then any dependencies for this Component will always be loaded into any Skuid Page, as long as the parent Component Pack is active.

2. The only dependencies that Component Packs deal with are customLabels, js and css.


pathsToChildComponents


  1. This is an advanced property that should be used whenever the component will render / contain other Components, addable via Component Acceptors from the Page Composer (we don’t have documentation on how to do this — yet — so this is pretty unlikely). For instance, if you are building an advanced layout component such as an Accordion, that can contain Child Components within the parts of the Accordion, then you’d need to use this, otherwise if you added a Component such as a Chart into your Accordion, Skuid will not know that it needs to load the dependencies for the Chart component at runtime.

So as far as what “paths” actually needs to look like: it’s roughly a “selector” syntax (CSS-style) of how to traverse your Component’s XML tree to find the nodes containing child components. As an example, the Tab Set component’s “pathToContents” property is T“tabs>tab>components”], because the Tab Set components’ XML structure is something like <skuidvis__chart… /><skootable… /> The property is an Array because there could be multiple paths to the locations of Child Components. If your component just has a root level node, then your pathToContents property would be u“components”]


Thanks Zach. A couple of follow-ups if you don’t mind…


alwaysLoad - This property and customLabelDepdencies are at the component level. However, js & css are at the pack level. Given your feedback, just want to make sure I’m understanding correctly that for a component that is marked alwaysLoad=true, any customLabelDependencies for that specific component plus all js and all css for the pack will be loaded, correct? Or can you specify js & css for the individual component and then only those are loaded and not the js & css at the pack level? The documentation doesn’t state js & css component level properties but based on your answer, I’m thinking that they might exist and it’s just not documented yet.


pathsToChildComponents - Selector syntax based on xml config makes sense. A few questions here:


  1. Currently the guidance (here) is to use factory methods when a custom component contains child components. Does using the pathsToChildComponents replace the need for this?

  2. Will Skuid walk the entire chain of components beyond the first level children when selector syntax is used? In other words, if the top level component contains components and those components contain components (e.g. <skootable…/>), will the entire chain be processed assuming the selector points to the top level only?

  3. How does the server side of child components come in to play for components that have corresponding APEX implementation?

Thanks!