Avoiding conflicts with non-standard fields in the Event model

[kujiy]

I see your doc recommends to use Non-standard Fields but it causes conflict error if fullcalendar has the same name option with the user's custom parameter in feature versions.

I think it's better to recommend to use with a reserved param like userField.

What do you think?

[arshaw]

i agree. this change is a little far-off, but i'll revisit this issue when rearchitecting the event model. thanks

[kujiy]

Thanks @arshaw . My team members were a bit annoied about this conflict error last week. The first developer knew Non-standard Fields and used lots of custom params. The other people added their original params like him but someone didn't read that manual and conflicted them with existing params like source and url in the manual. Those are common names you know. We fixed the problem by cooping them up inside userField. Anyway, I really appriciate your great project. Thank you again.

[arshaw]

understood. thanks @kujiy

[arshaw]

This issue has been addressed in the latest alpha release (4.0.0-alpha.2)
See the blog post »

https://fullcalendar.io/docs/v4/event-parsing

You can now specify an explicit extendedProps hash

[arshaw]

I'm closing this issue to signify that it's implemented (since v4-alpha2). I'll comment on this thread again when v4 is officially released.

[arshaw]

V4 was officially released a few days ago!