"The wiki's description is complete, but also confusing on first read:" - and not just on the first read! Haha, yeah, I should have put something along the lines of, "confusing until you grok it, and then you still aren't sure of the best way to describe it". It looks like orderSections loops through calling orderSection once for each named section. Looking at orderSections: attributes: this an object, but what does it contain exactly, and what does that object look like? sections: if I'm reading this correctly, its a group of sections and their ids, like { repeating_weapons: [-saghsuagisi, -ahgjhgbjgfs, -haygiu67t485ta], repeating_gear: [-w48yyhwity548, -esa74w67ytwagh] } (Not real IDs, just some keysmashing there!) Is that correct? Yep! you've pretty much got it. The attributes argument is just the object that you would get in the callback to getAttrs. E.g. getSectionIDs('repeating_section',(idArray)=>{
const sections = {repeating_section:[]};
const getArr = idArray.reduce((accumulator,id) => {
accumulator.push(`repeating_section_${id}_name`);
sections.repeating_section.push(id);
return accumulator;
},['_reporder_repeating_section']);
getAttrs(getArr,(attributes) => {
console.log(sections.repeating_section); // => the idArray in creation order
orderSections(attributes,sections);
console.log(sections.repeating_section); // => the idArray in true order
})
}); Also with the link you provided, I see the function getSectionIDsOrdered : what would code using that look like? The getSectionIDsOrdered function that is shown on the wiki isn't my favorite implementation of this because it nests your actual work in another getAttrs which as we both know causes problems, especially for something like this where you might need to do this action on 2, 3, 4, or even more repeating sections at once. Essentially, the orderSections code from the K-scaffold on the other hand goes the other direction and probably over obfuscates the functionality, but it does that because it's built to support the scaffold's automation features. If someone is building this infrastructure from scratch, using just the orderSection function as needed is probably plenty fine. For that matter, lets say I have an attribute inside a repeating section: the attribute is attr_number , the section is repeating_gear . What code would I need to update that number value to show the currently displayed row? (Maybe a redundant value, since you can see the repeating section, but bear with me :)) Assuming we're using the full orderSections code above, then we could just do this: getSectionIDs('repeating_section',(idArray)=>{
const sections = {repeating_section:[]};
const getArr = idArray.reduce((accumulator,id) => {
accumulator.push(`repeating_section_${id}_name`);
sections.repeating_section.push(id);
return accumulator;
},['_reporder_repeating_section']);
getAttrs(getArr,(attributes) => {
orderSections(attributes,sections);
const setObj = {};
sections.repeating_section.forEach((id,index) => {
setObj[`repeating_section_${id}_number`] = index;
})
setAttrs(setObj,{silent:true});
})
}); And, just because I can't resist plugging the scaffold, here's what a fully functional sheet would look like doing that using full K-scaffold: PUG include k-scaffold
+fieldset({name:'section'})
+number({name:'number',readonly:'',trigger:{
calculation:'getRowIndex'
}})
+text({name:'name',trigger:{
affects:['repeating_section_$X_number']
}})
+kscript
include ./javascript/getRowIndex.js ./javascript/getRowIndex.js /**
* gets the row index for a given row and returns it.
* @param {object} trigger - The trigger that caused the function to be called
* @param {object[]} sections - All the repeating section IDs
* @returns {number} - The row index
*/
const getRowIndex = function({trigger,sections}){
const [section,rowID] = k.parseTriggerName(trigger.name);
return sections[section].indexOf(rowID);
};
k.registerFuncs({getRowIndex}); Fixed some typos from me being tired. -_-
