Why can’t component IDs be reused in multi-page apps?

💬 Feature Requests
, ,
1

i tried giving a component an id that’s already used on another page, and got this error:

“Failed validation: ‘bmFilterSelect’ is a component that exists already on page purchaseOrders.”

the components aren’t global and live on separate pages, so i don’t get why this isn’t allowed. kinda sucks to have to prefix every id just to avoid conflicts. is there a better way to handle this?

2

Hey @Haider_Ali, I had a similar encounter with component objects (particularly a list view) which led me to a solution that isn't quite cumbersome, but it leans into the auto component naming which appends an sequence value on your components as you use them. bmFilterSelect and bmFilterSelect2 in your case could be accessed by a global function that looks for components with your naming convention in them and acquires their id for use in processing.

This does require use of global variables/states for reading data from the current page. In my case this is a variable that holds my list view instances currentInstances when a page loads which I then loop through to pull out the components:

 let controlKey = Object.keys(currentInstances[i]).find(key => key.startsWith('checklistControl'))
 let notesKey = Object.keys(currentInstances[i]).find(key => key.startsWith('checklistNotes'))
 let termsKey = Object.keys(currentInstances[i]).find(key => key.startsWith('checklistTerms'))

page 1 has checklistTerms as a TextBox component, page 2 has checklistTerms2 and so on. These are just a few of the items, but they are all sequential per page (automatically applied when I copied the original list view to the new page). Getting the data from each component is then just a return object using the values from the instance:

let result = await updateContractItems.trigger({
    additionalScope: {
      project: selectedRowData.value.project_num,
      id: currentChecklistData[i].id,
      answer: currentInstances[i][controlKey],
      notes: currentInstances[i][notesKey],
      action_type_state: currentInstances[i][actionKey],
      risk_notes: currentInstances[i][riskKey],
      flow_notes: currentInstances[i][flowDownKey],
      negotiated_terms: currentInstances[i][termsKey]
    } 
  })

I know this isn't an ideal solution (and may not necessarily fit your current case) but it is a way I have found to minimize the amount of component naming I need to do on this project.

3 Likes
3

Thanks, @pyrrho!

@Haider_Ali, we have a feature request to support same names on separate pages. It isn't currently being prioritized, but I can follow up here when it gets picked up

1 Like