Hello!
I was trying to integrate bootstrap to the event wrapper, by eventPropGetter where i added classnames and some styles, the problem was in the line 170 where overwrite width of any class of bootstrap like col-xs-, col-md-, etc
i think any possible solution is to move highlithed line 166

at final style props, like img:

that's was a nice solution to adding bootstrap classes to event wrapper.
tomorrow can be upload a pullrequest if yours want!
saludos!!!
Straggling with the same issue. Any chances it will be merged into master?
Overriding those styles will mess with the positioning of events. Is that what you want?
@tobiasandersen I am interesting in changing width and left \ right properties. This will help me to create more custom UI. (Overlapping events logic right now isn't the best choice for my scenario). It would leave changing of the top to the calendar and wouldn't mess with event position of the event in the day
I see. While that definitely is a valid use case, I'm a bit worried people would override these styles by mistake and in turn break the layout. Another solution that's been discussed briefly is to make the layout algorithm pluggable. At the end of the day, I guess it's a decision for @jquense to make.
Created a pull request #600
@tobiasandersen @jquense would mind to take a look?
Yeah, right now I think allowing this would be a footgun that I don't want to deal with support for. IN 99% of cases overriding these properties would be a bug. If we need more control over the layout there should be a proper API for it :)
Here's my solution. It's a bit hacky, but works just fine. Create some CSS class (I'm using SCSS here but other solutions should also work fine) and add !important property after the width.
Let's say you would like to have 30px width. Now:
calendarCustomization.scss:
.widthOverride {
width: 30px !important;
}
eventPropGetter:
import styles from './calendarCustomization.scss';
export function customEventPropGetter(event, start, end, isSelected) {
return { className: styles.widthOverride }
}
@skvark thank you, we also considered this solution, but discarded for being 'too much'. Ended up forking it. Hope to get back with much cleaner solution. Cheers