I really like the way the tags component are setup to add context to my detail page and such, but generally when you have tags in pills, you can click these tags to filter or refine the search results by the said tag. I don't see a way to associate any events with this component? Is this an oversight or is this component just pure visual and not of any functional use?
Thanks,
Hunter
hey @huntersinclairtiv ,
the tags component doesn't have event handlers attached to it, unfortunately.
if your HTML and CSS is up to scratch, you could almost assuredly do it with the HTML component
Thanks @DavidD - that is unfortunate. Yea I can write something in HTML - I would like to ideally map the list to a query result set, so not sure how best to do that in the HTML (if there is some way to loop through results to show multiple).
Do you know is there a way to convert the list component to horizontal? Or is there a grid component that could be mapped to the result set where I could maybe just drop in a button as the repeating object?
+1 for making tags in the Tags component actionable with event handlers!
We implemented a tagging system for our database (a tags table and a join table), and already had the Tags component in mind. Was very surprised to go implement the Tags component to find that the tags are not actionable.
I might write a custom component to accomplish this, however, for the interim I was able to create a reasonable facsimile of actionable tags out of the Link List component. In the upper component, a click triggers a detach query, and in the lower, an attach query. The prefix icons are very useful here.
Oh my it looks like my earlier post was totally off here 
thanks for the extra context! I've linked this thread to the internal request we have for adding event handlers to the tags component so that we can know to post an update if it's included!
I see that since this thread was created the tags component has gained handlers for click events. yay.
Other important points:
A tag component can be linked to a query.
The label and tooltip of a tag can be obtained via deconstruction of the query results. E.g., {{item["foo"]}} or {{item["bar"]}}.
But what I am seeing today is that {{item}} inside a Javascript event handler resolves to a string holding the tag label, but otherwise nothing else from the underlying query is visible.
Here is a simple example of how this hurts:
The quality and compliance domain is a collection of domains, technologies and standards which encompass all software quality, correctness, and conformance with applicable standards and regulatory mandates.
24b712a2-49ad-409b-8e06-217f92a4dea8
The quality and compliance domain...and regulatory mandates.
item resolves only to the elided string used to label the tag, not the full string or the id guid.Hi @Roland_Alden!
Great to see that tags triggering queries is helpful to users.
So to your second point, the query run does hold reference data to the label and tooltip of the tag that called this query to run.
However, your issue is that you are NOT able to get information about the query, such as query.data from the {{item}} inside the event handler for a click on a tag.
Are you looking to grab the non-shorted label/guid from the tag, or are you looking to get data about the response/results of the query?
I would be happy enough to just get the string that is labeling the tag.
Of course that string comes from the tag components underlying data and it might be "nice" to get the whole thing.
But I would be happy just getting the label.
Thanks for the info @Roland_Alden!
Could you share a screen shot of the "Javascript event handler" where you are looking at {{item}} ?
I thought you meant a run script on tag's click event 
but on testing remembered the scripts don't use {{}} since it is all JS.
I was also curious about your point 2 and where you are deconstructing the query results. Not sure if that is related but would love to see a screenshot.
If you can show me where you are getting The quality and compliance domain...and regulatory mandates. I can repro and look to fix this or file a FR!
Actually to be clear I am not using a tags "component". Sorry for that confusion.
I have a table where the column type is "keywords" which is probably not exactly a tag component even though it looks identical.
In that column there can be an event handler for a click cell event.
Note that inside the click cell handler item references the entire keywords array but there seems to be no information that will tell me which keyword the user clicked.
@Roland_Alden Ahhhhh ok I see, that makes a lot more sense, thank you for explaining this is a table component and not a tags component
Of all the column format types, "keywords" doesn't seem to be any of our options from the Format dropdown. So I am guessing you are using the Format Tags and you named the column with the Label of "keywords" 
Since the event handler is for the cell, it the table does not know which of the 10 items was clicked, just that the cell was clicked.
A workaround for this would be to use the Tags component! As each tag can return and log its specific content when clicked(as I found out from testing the Tags component).
My recommendation for a work around since a cell action is not able to specify which part of a cell was clicked, is to use Expandable rows, then you can nest in a Tags component under the row and these can pass the data of the individual tag when clicked and trigger a query 
It would be great if we ~could~ put the tags component inside of a cell and give the cell the ability to register which of however many tags was clicked. But the table's cell click event was not build with that idea in mind unfortunately.
The next best this is to use a component that does register which sub-component is clicked, and combine that within the table via expandable rows.
Hope this helps!
Yeah. Exactly. I will give that a try. Something that would be "nice". When I ask a table to make a column a "tags" type the option to execute all this configuration is presented. I would characterize this as "display-only" tags vs. "interactive tags".
Display-only tags is probably only "interesting" if it is significantly lighter weight, otherwise a tags component that ignores events would be a single solution.
@Roland_Alden I ran across something similar and used url.hashParams in an HTML component.
Have a look here. It might work in your case as well.
I tried Expandable rows and it was fine for a few rows but crashed when loading a few hundred rows.
I got the embedded tags component working. In my case the data set is quite small and it works fine. However I ran into one problem which is the table itself. When it has an "embedded component" it displays a control to expand/close each row.
I thought there was a way to make these rows be expanded by default. But I have not been able to find that setting. Having to open them manually is irritating and the expand/contract control takes up super-valuable left margin space.
@Roland_Alden If you run table1.expandRows() it will expand them all. You can add this to a script or JS Query on page load or whenever the user is going to look at the table data.
Unfortunately yes it does take up some left margin space. If you can't work around the sizing, check out Shawn's link above for a different work around!
Interestingly both
table_foo.expandRows();
and
table_foo.expandRows({mode:'all'});
"work" if executed in the debugger. However, during an operation that adds a row to the table I end that javascript with:
await scratchpad_read.trigger();
Which reloads the data that is feeding the table. The next statement is then
table_foo.expandRows();
and I have tried
await table_foo.expandRows();
Neither works. Yet after the table has been updated if I run table_foo.expandRows(); in the console the new row will expand.
@Roland_Alden Interesting that the expandRow function doesn't seem to run after await scratchpad_read.trigger();
May need to just have the expand Row method run in a JS Query and have it inside the 'On Success' handler for the query.
That seems to work but unreliably.
If the scratchpad_read query has Run event handlers after (ms) set to some non-zero value this helps. I first tried 1000 which worked, then reduced it to 100 which worked too. But then it didn't. I raised it back to 1000.
Using await on table2.expandRows({mode:'all'}); in the success handler also seems to help.
While testing I thought that table2.expandRows({mode:'all'}); was behaving differently than table2.expandRows(); but I doubt that is true. What is true is that the expand all operation just seems to be flakey.
