Issue with log view

[akoevroman]

There is an issue with this library if there is anything extra in the response.
For example, our API returns the build version for any request, and for some reason, this also affects the library itself.

I think that parser should have its own associative array with log files and not just do a foreach of everything that the request has

[arukompas]

@akoevroman hey! Did you override/modify the FoldersController ? Or apply middleware that modifies responses?

Log Viewer does not return this "meta" property with the folders response.

Log Viewer's frontend is built to expect specific responses, which the Log Viewer backend provides. They work well together out of the box. But if there's any modifications made to these requests/responses, it may not work as expected and that is outside the scope of this package.

Log Viewer currently doesn't support response modifications. So if there's anything in your project that modifies responses - it's also your responsibility to modify & rebuild the frontend to correct accept the new responses.

But I see your point - Laravel usually wraps data in a "data" top-level property, and at this point Log Viewer does not do that. It would be a breaking change at this point (if the user updates Log Viewer package, but doesn't publish new updated frontend build), so I'm hesitant to change it.

I'll have a think whether there's a clean solution to move to a top-level "data" property instead, but it's not trivial at this point.

[akoevroman]

@arukompas

hey! Did you override/modify the FoldersController ? Or apply middleware that modifies responses?

Yes, I did. In the API, we have middleware that modifies the response.

I'll have a think whether there's a clean solution to move to a top-level "data" property instead, but it's not trivial at this point.

Yes, this is actually what I was talking about. It's not a big deal; I solved my issue with exclusion for a specific URL or the admin panel, but this just highlights an architecture problem.