Closed alexaverill closed 2 weeks ago
Additionally I added some config files and definition files to the global gitignore to help avoid them being committed to source control
@alexaverill Thanks for this contribution—this has been a nagging problem that I haven't been able to track down.
Given that you are addressing it in the frontend (exhibitera_setup_common.js
), do you think it's necessary to also address it on the backend (helper_files.py
). It seems like that might introduce unexpected behavior if there is ever a valid reason to write JSON with a key of value s
.
I am honestly on the fence about removing it in both places, my main thinking is that if there is a setup that isn’t using the shared code, it would be caught in the backend, and removed. It was really meant as defensive code.
I also think it’s fairly unlikely that using a key of just ‘s’ would be a common or expected use case, and if it was causing unexpected behavior it would be easy to remove.
Regardless, if you are fairly confident that the shared library is used across the board I would agree that having it in the backend is extraneous, and I can pull it out.
The color picker library is only used during setup and writing definitions should always use exhibitera_setup_common
, so I think it is safe to enforce only on the client side. Once that is removed, I will accept the PR!
Sounds good, I just pulled it out!
I noticed when Exhibitera is generating definition files for applications its generating a pretty extraneous nested object that I don't believe are used anywhere. Example Definition file before:
Example After:
I added a filter to the front end input, as well as where it get saved in case there is an instance not covered by the frontend changes.