-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Makes Host Project Layouts Available via beacon_site
macro
#431
base: main
Are you sure you want to change the base?
Conversation
…ter.__options__/1
Hey @ddink I appreciate the PR!
Unfortunately there's a drawback that is caused by the fact that Beacon requires some functions in the root layout in order to work properly ⬇️ beacon/lib/beacon_web/components/layouts/runtime.html.heex Lines 5 to 12 in 4614733
If you don't provide those functions, Beacon rendering breaks or at least cause undesired behavior like not connection to LV, not rendering data that you'd expect it would render on pages, missing styles, and so on. Ideally we want to find a solution to "merge" or "inherit" layouts instead of just overwriting it because it needs both Beacon and your app functionality. Does it make sense? I'm still not sure what's the best approach but I hope this gives some light why I din't merge this one yet. |
Hi @leandrocp yea I understand the dilemma here. It does make sense for Beacon to be focused on its own root layout. However, I would first consider whether or not all applications using Beacon will use the CMS universally. Using Beacon’s necessary layout functions in our existing layout caused issues with the existing live views in our codebase. Beacon pages come with some overhead that can’t be left out (such as the Additionally, our application has The way we’re getting around it is by 1) overriding Beacon’s The thing for us is that we designed our application so that the non-CMS pages don’t need any CMS-able components (although, it would definitely be worth it to have that functionality available to non-CMS pages at some point). I think the difficulty for Beacon is how do you make dynamic pages available to the CMS for editing without eliminating the practicality of just having dynamic pages that don’t depend on the CMS? I can already access the necessary data to build our dynamic pages from within Beacon. But doing so is also impractical. Keeping those live view templates in our codebase makes it easier for us to edit, version control, and has the bonus benefit of preventing non-engineers from mistakenly breaking anything. We get more flexibility from not using Beacon as a monolith. In other words, we don’t need to override Beacon’s In our case at least, it would be more practical for our codebase to have access to Beacon’s components outside of the CMS—perhaps via a function call that doesn’t require Beacon’s overhead (something like I’m not trying to disagree with Beacon’s approach here, so much as making the argument that there are use cases for Beacon that don’t include its use as a monolith. Our application is an umbrella where the web interface application is just one of several child apps. Having the option to use Beacon without it being the only way that we make changes to our web interface is our ideal use case. Being able to incorporate Beacon’s components into our dynamic pages would be a step further in the direction of our ideal use case. |
d016a18
to
c443ff9
Compare
What will it allow you to do that you can't do today?
These changes make it possible to define the
root_layout
andon_mount
session options that are passed into thelive_session
in thebeacon_site
macro (viaBeacon.Router.__options__/1
).Adding these changes allow the host project to use an existing layout to house Beacon's content.
Then the only thing that has to be done to use these options is to pass the additional options into the
beacon_site
call as a keyword list:Why do you need this feature and how will it benefit other users?
This feature is a business need. It will benefit other users by giving them the ability to use a layout that's defined in their host project. It will also allow other users to leverage the
on_mount
session option on all Beacon pages.Are there any drawbacks to this feature?
I don't see any drawbacks to this feature since it only configures the options that are already available for change
in
Phoenix.LiveView.Router.live_session/3
.