Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
kevbrowndev opened this issue Jul 2, 2022 · 21 comments
Open

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

kevbrowndev opened this issue Jul 2, 2022 · 21 comments
Assignees
@poorejc
Labels
enhancement

Comments

@kevbrowndev
Copy link
Contributor

kevbrowndev commented Jul 2, 2022 •
edited

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.
@kevbrowndev kevbrowndev changed the title Provide a means for users to data attributes HTML elementss Provide a means for users to log data attributes HTML elementss Jul 2, 2022
@kevbrowndev kevbrowndev changed the title Provide a means for users to log data attributes HTML elementss Provide a means for users to log data attributes on HTML elementss Jul 2, 2022
@kevbrowndev kevbrowndev changed the title Provide a means for users to log data attributes on HTML elementss Provide a means for users to log data attributes on HTML elements Jul 2, 2022
@kevbrowndev kevbrowndev changed the title Provide a means for users to log data attributes on HTML elements Provide a means for users to log HTML elements data attributes Jul 3, 2022
@kevbrowndev kevbrowndev changed the title Provide a means for users to log HTML elements data attributes Provide a means for users to easily log HTML elements data attributes Jul 3, 2022
@EandrewJones
Copy link
Contributor

@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
Copy link
Contributor Author

kevbrowndev commented Jul 3, 2022 •
edited

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

@poorejc poorejc self-assigned this Jul 16, 2022
@poorejc
Copy link
Contributor

poorejc commented Jul 16, 2022 •
edited

@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:

image

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
Copy link
Contributor

poorejc commented Jul 16, 2022

@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
Copy link
Contributor

@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
Copy link
Contributor

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
Copy link
Contributor

poorejc commented Jul 22, 2022

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
Copy link
Contributor

brucearctor commented Jul 22, 2022 •
edited

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
Copy link
Contributor

EandrewJones commented Jul 22, 2022 via email

@poorejc
Copy link
Contributor

poorejc commented Aug 30, 2022

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'.

@poorejc poorejc mentioned this issue Oct 7, 2022
Closed
@kevbrowndev
Copy link
Contributor Author

kevbrowndev commented Oct 11, 2022 via email

@Jyyjy
Copy link
Contributor

Jyyjy commented Nov 2, 2022 •
edited

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.

UMD-ARLIS@5e9d79d#diff-335fef3882ddae658927db1ff4aedd68f5a8d548272979d41d112955f765ceca

@Jyyjy Jyyjy mentioned this issue Jan 4, 2023
Merged
@poorejc
Copy link
Contributor

poorejc commented Jan 29, 2023

check out @Jyyjy commits for an example of this, now on MASTER see: 8336f4e

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 dev@flagon.apache.org or user@flagon.apache.org.

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

@EandrewJones
Copy link
Contributor

EandrewJones commented Jan 30, 2023 via email

@kevbrowndev
Copy link
Contributor Author

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
Copy link
Contributor

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

@Jyyjy
Copy link
Contributor

Jyyjy commented Jan 17, 2024

@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
Copy link
Contributor

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

And then can we close this?

@Jyyjy
Copy link
Contributor

Jyyjy commented Jan 17, 2024

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
Copy link
Contributor

Jyyjy commented Feb 17, 2024

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
Copy link
Contributor

EandrewJones commented Feb 18, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@poorejc poorejc

Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@kevbrowndev @brucearctor @poorejc @EandrewJones @Jyyjy