Provide a means for users to easily log HTML elements data attributes

[kevbrowndev]

Some users have expressed interest in this functionality. Would it be okay if I added it to userale?

How to do it?

I was thinking of a key called datasets on the log that takes key value pairs of data attributes in each. There would also be a new parameter for userale called datasetproperties that takes an array of string values. Each string value would be the name of a data attribute.

• We could have a new function that uses the dataset API to get any of these that might exist from each element, and in packageLigs.js file call this function to set the datasets property of the log.

• This could be controlled by users with a new parameter on userale called datasetproperties that takes an array of strings.

So for example,a user could add a parameter to userale called datasetproperties with the value of ['data-id','data-name'] and then in the code whenever these special data attributes are set on elements, they will be logged in the appropriate log payload.

[EandrewJones]

@kevbrowndev I added very similar functionality to a customized build of UserALE for a project I was working on. It was done on the fly I didn't do it on a fork of the repo.

If there's enough interest, I could fork the repo and push a draft PR for others to iterate on / productionize.

[kevbrowndev]

Neat. I have the same actually. :-) Maybe we can compare notes?

[poorejc]

@kevbrowndev @EandrewJones wow timing is impeccable--of course I'm two weeks late to the convo :)

Some students I've been working with have been doing some work in pulling attributes from SVG docs embedded in pages and adding those attributes to custom logs. EX: clicking around on an interactive dashboard map on apache superset, can we extract data attributes embedded within svg docs? Here's what extracted attributes look like:

Methods are slightly more complicated than retrieving html attributes via .getAttribute() (have to parse xml first), so unsure that .dataset method will work uniformly (or at all for our use case), however, certainly the intent of the extracted data is the same.

Would love to coordinate with you all on modifying the UserALE.js data schema to specifically accommodate attached properties embedded in docs. Currently, we're using custom logs with custom fields--standardized option would be better. Might be able to engineer together an elegant common solution that uses new UserALE.js params in userale.options() to invoke fuctions to extract attributes from different sorts of docs (html, xml). @kevbrowndev is this what you had in mind? If, we're on the same page there, then yes packageLogs.js is exactly the right place to embed those functions. Might also expose them through the API to assist custom log scripting....

@kevbrowndev @EandrewJones can you share some examples here? I'll work with my students to do the same.

[poorejc]

@kevbrowndev I added very similar functionality to a customized build of UserALE for a project I was working on. It was done on the fly I didn't do it on a fork of the repo.

If there's enough interest, I could fork the repo and push a draft PR for others to iterate on / productionize.

Happy to open up a dev branch on this ticket. Could fork and merge there. Sound right?

[EandrewJones]

@kevbrowndev @poorejc Here are the modifications I made to packageLog.js in my build.

I wrote a function buildDatasets that creates an array of data-attributes maps for the event target and all elements in the path to that target. Then I added it to the log object in the primary export function, packageLog:

/**
 * Transforms the provided HTML event into a log and appends it to the log queue.
 * @param  {Object} e         The event to be logged.
 * @param  {Function} detailFcn The function to extract additional log parameters from the event.
 * @return {boolean}           Whether the event was logged.
 */
export function packageLog(e, detailFcn) {
  if (!config.on) {
    return false;
  }

  let details = null;
  if (detailFcn) {
    details = detailFcn(e);
  }

  const timeFields = extractTimeFields(
    e.timeStamp && e.timeStamp > 0 ? config.time(e.timeStamp) : Date.now()
  );

  let log = {
    target: getSelector(e.target),
    path: buildPath(e),
    datasets: buildDatasets(e),
    pageUrl: window.location.href,
    pageTitle: document.title,
    pageReferrer: document.referrer,
    browser: detectBrowser(),
    clientTime: timeFields.milli,
    microTime: timeFields.micro,
    location: getLocation(e),
    scrnRes: getSreenRes(),
    type: e.type,
    logType: "raw",
    userAction: true,
    details: details,
    userId: config.userId,
    toolVersion: config.version,
    toolName: config.toolName,
    useraleVersion: config.useraleVersion,
    sessionID: config.sessionID,
  };

  if (typeof filterHandler === "function" && !filterHandler(log)) {
    return false;
  }

  if (typeof mapHandler === "function") {
    log = mapHandler(log, e);
  }

  logs.push(log);

  return true;
}

...

/**
 * Builds an array of data-attribute maps for all the event target and all elements
 * in the path to the target.
 * @param {Object} e Event from which the data-attrbute array should be built.
 * @returns {HTMLEelement[]} Array of maps for target and all ancestors, if they exist.
 */
export function buildDatasets(e) {
  let datasets = [];
  let ele = e.target;
  while (ele) {
    if (ele.dataset && Object.keys(ele.dataset).length > 0) {
      datasets.push(ele.dataset);
    }
    ele = ele.parentElement;
  }

  return datasets;
}

[brucearctor]

It reads as if there is an interest in this functionality. As long as that's the case, then it seems time for actual code and an eventual PR for something concrete to review?

If any doubt, I'd suggest to bring to the list to ensure such a contribution would be welcome - before devoting too much time to coding it. This sounds like an addition of a little feature, not a major direction change, and therefore not really warranting a more thorough RFC.

[poorejc]

It reads as if there is an interest in this functionality. As long as that's the case, then it seems time for actual code and an eventual PR for something concrete to review?

If any doubt, I'd suggest to bring to the list to ensure such a contribution would be welcome - before devoting too much time to coding it. This sounds like an addition of a little feature, not a major direction change, and therefore not really warranting a more thorough RFC.

@brucearctor I think the case is that we have three different teams working with UserALE who have been working on extracting additional data and each have our own custom solutions--code has already been written. At this point, I think we need to get a sense of what we're each doing (such as what @EandrewJones shared--THANK YOU!) and see if we can coordinate on a way to integrate common features in to the core logging engine that makes it easier to access requisite functionality out of the box.

Agree though that we should bring @dev into this to get some more opinions on an elegant solution.

Early next week, I'll open up a dev branch linked to the ticket and bring the ticket to the attention of the list.

[brucearctor]

I have to imagine that any written code would be best viewable and open for discussion. Ex: on a fork or branch, potentially as draft PR, etc.

3 different groups each with custom solutions: Are 'custom' solutions OK to merge/contribute, and potentially clean up and combine later? Or, are hoping to use what has been learned from each to develop a more generic solution [ no judgement on either at this time, looking to understand/establish community conventions ]?

[EandrewJones]

I could certainly fork and push to a draft PR.

My opinion is that it would be best to see all three implementations, hear more about all three use cases, and then try to come up with a generic and elegant solution that covers all three.

Best

Evan Jones 郑恩尉

Website: www.ea-jones.com

On Thu, Jul 21, 2022 at 10:31 PM brucearctor @.***> wrote:

I have to imagine that any written code would be best viewable and open for discussion. Ex: on a fork or branch, potentially as draft PR, etc.

3 different groups each with custom solutions: Are 'custom' solutions OK to merge/contribute, and potentially clean up and combine later, or are hoping to use what has been learned from each to develop a more generic solution [ no judgement on either at this time, looking to understand/establish community conventions ].

— Reply to this email directly, view it on GitHub https://github.com/apache/incubator-flagon-useralejs/issues/266#issuecomment-1192116413, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJ2T6AKX3JSAPT6ETLH4JVLVVIBZPANCNFSM52PYSGMQ . You are receiving this because you were mentioned.Message ID: @.***>

[poorejc]

Sorry for delay in following up on this thread:

Here is another example implementation for grabbing specific fields in xml docs attached to SVG graphics: https://github.com/UMD-ARLIS/superset/blob/01aef7425939188063fba1eca254b8a9d647f84b/arlis-added/js/lib/custom.js

Essentially, this example detects embedded XML attributes in target path (e.g., svg .path[SVG...]), then parses the xml, extracts the desired fields, and adds extracted meta data to new fields via 'packageCustomLog'.

[kevbrowndev]

Sounds good. I'll share my approach via fork this weekend.

On Thu, Jul 21, 2022, 10:41 PM Evan Jones @.***> wrote:

I could certainly fork and push to a draft PR.

My opinion is that it would be best to see all three implementations, hear more about all three use cases, and then try to come up with a generic and elegant solution that covers all three.

Best

Evan Jones 郑恩尉

Website: www.ea-jones.com

On Thu, Jul 21, 2022 at 10:31 PM brucearctor @.***> wrote:

I have to imagine that any written code would be best viewable and open for discussion. Ex: on a fork or branch, potentially as draft PR, etc.

3 different groups each with custom solutions: Are 'custom' solutions OK to merge/contribute, and potentially clean up and combine later, or are hoping to use what has been learned from each to develop a more generic solution [ no judgement on either at this time, looking to understand/establish community conventions ].

— Reply to this email directly, view it on GitHub < https://github.com/apache/incubator-flagon-useralejs/issues/266#issuecomment-1192116413 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AJ2T6AKX3JSAPT6ETLH4JVLVVIBZPANCNFSM52PYSGMQ

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/apache/incubator-flagon-useralejs/issues/266#issuecomment-1192120929, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOZLZ53GRWXEHY7YRBLEM3VVIC4NANCNFSM52PYSGMQ . You are receiving this because you were mentioned.Message ID: @.***>

[Jyyjy]

I am working with @poorejc on adding this feature. I started with @EandrewJones buildDatasets() function. I tested it, it worked, and then there was a discussion on what information we actually want in the log messages. Right now this is where we are at:

• We want all attributes, not just dataset attributes.
• We only want attributes of the event target.
• We want to parse JSON values

I wanted to share this code snippet that does the above, and see what others think should be included in a log.

https://github.com/UMD-ARLIS/incubator-flagon-useralejs/commit/5e9d79d75d90c52aec9b2d4563094479b5af5f84#diff-335fef3882ddae658927db1ff4aedd68f5a8d548272979d41d112955f765ceca

[poorejc]

check out @Jyyjy commits for an example of this, now on MASTER see: https://github.com/apache/incubator-flagon-useralejs/commit/8336f4e4491afeddd9f27f56b0acefa503e3f6e0

Also find the example in the /examples file.

Would like to bring discussion of incorporating this into core UserALE.js behavior (perhaps through an API or html/.js config) over to [email protected] or [email protected].

Am curious is this is the kind of thing @kevbrowndev @EandrewJones you were looking for.

[EandrewJones]

This should capture what I was looking for. Though, to be honest, the specific use case requirements to which I customized the UserALE codebase to was almost a year ago now. Details are fuzzy.

Best

Evan Jones Website: www.ea-jones.com

On Sun, Jan 29, 2023 at 3:01 PM poorejc @.***> wrote:

check out @Jyyjy https://github.com/Jyyjy commits for an example of this, now on MASTER see: 8336f4e https://github.com/apache/incubator-flagon-useralejs/commit/8336f4e4491afeddd9f27f56b0acefa503e3f6e0

Also find the example in the /examples file.

Would like to bring discussion of incorporating this into core UserALE.js behavior (perhaps through an API or html/.js config) over to @.*** or @.***

Am curious is this is the kind of thing @kevbrowndev https://github.com/kevbrowndev @EandrewJones https://github.com/EandrewJones you were looking for.

— Reply to this email directly, view it on GitHub https://github.com/apache/incubator-flagon-useralejs/issues/266#issuecomment-1407756389, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJ2T6AKLOHSRN4MUFHVL4YTWU3EAPANCNFSM52PYSGMQ . You are receiving this because you were mentioned.Message ID: @.***>

[kevbrowndev]

Yes I say the same. It looks good but I haven't looked at it in a while. I am planning to try it out locally as time permits.

[EandrewJones]

@Jyyjy Did we not merge a PR that closes this ticket?

[Jyyjy]

@Jyyjy Did we not merge a PR that closes this ticket?

We merged an example of how to use custom logging for attributes, but it is not in the core package.

https://github.com/apache/flagon-useralejs/tree/master/example/log-attribute-example

[EandrewJones]

Curious: Was there a reason we decided against adding to the core package?

And then can we close this?

[Jyyjy]

There was no reason against adding it. I think there wasn't clear consensus on if the example is what everyone wanted in the core package

[Jyyjy]

I'm going to delete the example code and move the functionality into packageLogs, if there are no objections.

https://github.com/apache/flagon-useralejs/tree/master/example/log-attribute-example

[EandrewJones]

No objections here. Please include.

Best

Evan Jones Website: www.ea-jones.com

On Sat, Feb 17, 2024 at 6:49 PM Jason Young @.***> wrote:

I'm going to delete the example code and move the functionality into packageLogs, if there are no objections.

https://github.com/apache/flagon-useralejs/tree/master/example/log-attribute-example

— Reply to this email directly, view it on GitHub https://github.com/apache/flagon-useralejs/issues/266#issuecomment-1950571667, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJ2T6AJOENDNZI2NNQ7T2OLYUE6X5AVCNFSM52PYSGM2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJVGA2TOMJWGY3Q . You are receiving this because you were mentioned.Message ID: @.***>

[EandrewJones]

@Jyyjy Is this done?

[Jyyjy]

https://github.com/apache/flagon-useralejs/commit/4eec2ffd87880bc96858f2802b054058eeebb003