search

kean / Pulse

Network logger for Apple platforms
https://pulselogger.com
MIT License
6.37k stars 311 forks source link

Provide public access to ConsoleDatasource #278

Closed AvdLee closed 2 months ago

AvdLee commented 4 months ago

This opens up some of the APIs to allow fetching entities outside of PulseUI. This is great of building custom UIs or a custom Console.

kean commented 4 months ago

I think I have an idea for how to organize it that could also help me manage the "Pulse for Mac" codebase: move these internal dependencies to a separate module so that they don't "pollute" the PulseUI namespace but are still there if you need them.

AvdLee commented 4 months ago

@kean that makes total sense to me. While it's UI related code, they aren't really User Interface definitions. (In theory, you could use these data fetchers for non-UI work)

kean commented 4 months ago

I made a couple of changes in main to make it easier to contribute. The biggest changes are the removal of the pbxproj file and the CocoaPods support (long overdue), so it's now easy to update the project structure.

I also made an initial attempt to extract these API to a separate module: PulseComponents https://github.com/kean/Pulse/pull/280. I don't think it's a sustainable approach. With the amount of internal APIs RocketSim seems to be using, the best option would be to build these new views as part of the PulseUI framework, so that RocketSim could easily benefit from the future updates to PulseUI and the community could benefit from the updates coming from RocketSim.

AvdLee commented 4 months ago

@kean makes total sense! Honestly, for me it would be much better to have this inside PulseUI too! I think it makes more sense for the framework to keep these methods private.

Are you going to continue with PulseComponents or close that journey? I rather wait for that to complete before starting my code migration if that makes sense.

kean commented 4 months ago

Are you going to continue with PulseComponents or close that journey?

It was an experiment to check if it's a viable option, which it is, but I don't think there is value in shipping these public APIs. I also can't commit to supporting these in the future, as I can't say that I'm happy with many of the internal APIs in PulseUI. On the other hand, I'd be more than happy to add more customization options and new high-level views in the API.

kean commented 2 months ago

I ended up using Git submodules for my project (same as before) – sometimes the old ways are better than the new 😴

In this project, I'm redefining Pulse and PulseUI packages, adding their original sources, and extending them with my own code. This way, I get access to all of the internal package APIs.

A better option, but the one that requires a bit of work, is to use a package modifier. Unfortunately, I learned about it too late. It seems to be quite flexible, and I will invest in it in the future, but I'm not sure if it will be possible to avoid git submodules.

I'm going to close the PR in this form if you don't mind.