Introduce ReturnFormat option to allow detailed or value-only outputs

[faizanu94]

This Pull Request addresses #8 by introducing a new ReturnFormat option to the CSSStyleObserver. This enhancement allows users to choose between receiving only the current values of observed CSS properties or detailed information that includes previous values and change statuses

Changes

• Introduced the ReturnFormat enum with options VALUE_ONLY (default) and OBJECT
• Updated the CSSStyleObserver class to process observed properties based on the selected ReturnFormat
• Updated the README.md to reflect the new ReturnFormat option and provide usage examples

[bramus]

For the extended return format I’d like to retain the original object structure instead of changing to an array. So it’d be something like this:

    {
        "--my-variable": {
            "propertyName": "--my-variable",
            "value": "1.0",
            "previousValue": "0.0",
            "changed": true
        },
        "display": {
            "propertyName": "display",
            "value": "block",
            "previousValue": "block",
            "changed": false
        },
    }

That way, it’s easy to switch between return formats. If authors want to easily loop, they can always pass this result into Object.entries/Object.values.

Does that make sense?

[faizanu94]

Absolutely, that makes sense and would simplify switching between return formats - I have made the changes accordingly!

I did notice that the propertyName is duplicated both as the key and within each CSSPropertyInfo object. To avoid redundancy, perhaps we could omit the propertyName field inside the object since the key already provides that information. This would make the structure cleaner:

{
    "--my-variable": {
        "value": "1.0",
        "previousValue": "0.0",
        "changed": true
    },
    "display": {
        "value": "block",
        "previousValue": "block",
        "changed": false
    }
}

your thoughts on this?

[bramus]

Yeah, makes sense. Devs should use Object.entries() when looping the results.

[bramus]

Thanks for the updates!

There is still some unnecessary dependency chain between the functions here, namely _returnFormatHandlers calling _processObservedVariables, which I think can be avoided.

Ideally these two functions would be decoupled, so that they are standalone:

• _processObservedVariables to only return a list of changes
• _returnFormatHandlers to only return a formatting function

The _handleUpdate function can then tie them together, by passing the list of changes into the handler, after which it passed those formattedChanges into the _callback.

[bramus]

Can you refactor this so that it does not call processChange here, but that it only stores the change object?

[faizanu94]

refactored as requested

[bramus]

Ideally, these would only return a processing function, not actually call _processObservedVariables

[faizanu94]

refactored as requested