I disagree with the advise given here.
In a good software architecture you limit the knowledge about other structures to a minimum.
And information that correspondents to each other should be as close to each other, ideally so it is on the same screen, only as a last resort in different files. If they are in different files, you should add a comment, that changes here require also changes there.
In the proposed solution the PluginEditor needs knowledge of the members of the sub panel in order to create the connection. Now you cannot change the panel without changing the PluginEditor.
The Panel needs to expose its component, which violates the practice of encapsulation, one of the three pilars of OO design.
A nice paradigm that was posted here on the forum a while back was to add the component with the attachment together in a little struct:
struct AttachedSlider
{
AttachedSlider (juce::AudioProcessorValueTreeState& state, juce::String paramID)
: attachment (state, paramID, slider) {}
juce::Slider slider;
juce::AudioProcessorValueTreeState::SliderAttachment attachment;
};
Which you can use in your panel like:
private:
juce::AudioProcessorValueTreeState& state;
AttachedSlider gain { state, "gain" };
What shows that this solution of forwarding the APVTS makes sens is, that you don’t need to include anything to make it work. No extra knowledge of any details is needed.
Hope that helps