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
We should give the option for editors to add a list of events from a specific organizer in the sidebar of articles. I think the main use for this would be the sports articles which could list upcoming games for the discussed sport.
We could have a character field for each parameter we might query (for example look at the parameters in this api request: https://ubyssey.ca/api/events/?host=UBC%20Computer%20Science&location=Zoom) but that also seems really annoying because we might want to keep adding to the block when we add a new parameter which would make it unwieldy and mostly those fields won't be used. Also its a further abstraction from how we are actually retrieving the events which could feel strange. I would expect editors to frequently add text with the wrong casing or with extra whitespace, or specify too many unnecessary parameters. We could just have a url field with the api request (which I personally would like because I could check the result of the request immediately) but editors probably won't like that.
Also there is the question of whether to client side render or server side. Client side could be better because then the sql query wouldn't increase page load time. Caching kinda solve that though. Also server side is simpler to implement.
The text was updated successfully, but these errors were encountered:
We should give the option for editors to add a list of events from a specific organizer in the sidebar of articles. I think the main use for this would be the sports articles which could list upcoming games for the discussed sport.
We could have a character field for each parameter we might query (for example look at the parameters in this api request: https://ubyssey.ca/api/events/?host=UBC%20Computer%20Science&location=Zoom) but that also seems really annoying because we might want to keep adding to the block when we add a new parameter which would make it unwieldy and mostly those fields won't be used. Also its a further abstraction from how we are actually retrieving the events which could feel strange. I would expect editors to frequently add text with the wrong casing or with extra whitespace, or specify too many unnecessary parameters. We could just have a url field with the api request (which I personally would like because I could check the result of the request immediately) but editors probably won't like that.
Also there is the question of whether to client side render or server side. Client side could be better because then the sql query wouldn't increase page load time. Caching kinda solve that though. Also server side is simpler to implement.
The text was updated successfully, but these errors were encountered: