I am developing a paid plugin (don't know whether it's ok to public) where I need to set a category specific setting. Therefore, I compare several possible ways and proposal my suggestion.
With existing convenient custom_fields, it's intuitive to put category-specific settings in the CategoryCustomField
. discourse-solved takes this approach. Solved plugin uses the setting to permit action in server, while I am also interested in knowing the category settings in the client when user opens the category chooser or composer.
Settings in Category's custom_fields
Category has 3 serializers. 2 of them:
BasicCategorySerializer
Discourse preloads categories by BasicCategorySerializer
with initial HTML.
If discourse serializes custom_fields
by BasicCategorySerializer
, we'll know setting details without asking the server again. The drawback is custom_fields may be huge.
CategorySerializer
Right now, discourse serializes custom_fields
for category by CategorySerializer
. In client site, we may ask Category.reloadById
to get more data about category including custom_fields
. For the record, it's invoked by editCategory(category)
in routes/application.js when you click Edit category button.
A client plugin have to get category details before access category specific details. The client can change states after getting the result. The drawback could be many GET requests and asynchronous.
Plugin who is interested in category-specific setting
A client plugin may query when:
- When user changes category in category chooser.
- Delay
- GET requests based on changing category.
- When category chooser is loaded, clients load all category settings.
Proposal
Here it's all three ways to enable category specific settings in my mind. While I may be terribly wrong, it's good to hear some feedbacks
- Moving category custom_fields to BasicCategorySerializer from CategorySerializer. I suppose initial payload size is critical. It's not a good idea.
- Creates an custom_fields endpoint to allow batch querying.
- Uses some site settings or cache?