You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Stimulus is the obvious choice, and could be wrapped in a twig component to make it even easier.
Brainstorming about the format.
{# events is an array of events, event contains at a minimum keys of title and start) #}
<div {{ stimulus_controller('calendar', {
events: events
})) }}>
</div>
OR
<twig:Calendar :events="events" />
Obviously, we'll want to move the twig component and stimulus controller to the bundle, but it's considerably easier to work in the demo app first. But when that happens, the developer simply needs to create events, e.g.
$dt = new \DateTime(); // for the demo, start with the current date$events = [];
$events[] = ['title' => 'now()', 'start' => $dt->format('c')];
$events[] = ['title' => 'Set Goals', 'start' => $dt->format("Y-m-01")];
$events[] = ['title' => 'Reflect', 'start' => $dt->format("Y-m-t")];
And pass them to the twig template, and in twig, call the component. ZERO JAVASCRIPT from the developer! Even what libraries to load will be hidden, since the bundle auto-registers everything, as long as the base loads the assets:
So before moving the stimulus controller and twig component to the bundle, what are the options we want to expose via attributes? Obviously events and initialView, which for my application was actually enough to be usable. But fullcalendar has TONS of options, I imagine we'll start with the easy ones. I'm working on the icalendar plugin first.
The text was updated successfully, but these errors were encountered:
One of the goals of this bundle could be to be able to customize fullcalendar without ever writing javascript. That is, to replace the section https://github.com/tattali/CalendarBundle#basic-functionalities with some twig calls.
Stimulus is the obvious choice, and could be wrapped in a twig component to make it even easier.
Brainstorming about the format.
Both of these work in the demo app at https://github.com/tacman/micro-calendar
Obviously, we'll want to move the twig component and stimulus controller to the bundle, but it's considerably easier to work in the demo app first. But when that happens, the developer simply needs to create events, e.g.
And pass them to the twig template, and in twig, call the component. ZERO JAVASCRIPT from the developer! Even what libraries to load will be hidden, since the bundle auto-registers everything, as long as the base loads the assets:
So before moving the stimulus controller and twig component to the bundle, what are the options we want to expose via attributes? Obviously events and initialView, which for my application was actually enough to be usable. But fullcalendar has TONS of options, I imagine we'll start with the easy ones. I'm working on the icalendar plugin first.
The text was updated successfully, but these errors were encountered: