Support `usePuck` without custom interfaces or overrides about puck HOT 2 OPEN

Strongly in favour of Option 1: PuckContext, which mirrors the approach of react-map-gl: https://visgl.github.io/react-map-gl/docs/api-reference/map-provider

I don't want to have to decompose the editor UI in order to update Puck's internal state.

from puck.

@janbaykara I don't think there is a requirement to decompose in option 2 - it's mostly semantic

Option 1 vs option 2:

• Puck.Context vs Puck
• Puck vs Puck.Default

The reason I introduced option 2 was because I don't want to introduce a breaking change to how Puck's context is defined by requiring users to specify a PuckContext wrapper. You could get around that by checking whether or not the Puck component is wrapped within a PuckContext, and only setting up the context inside Puck if there's no wrapper.

from puck.