Garrett Coakley
https://polytechnic.co.uk
•
Mar 15
nitinthewiz
https://github.com/nitinthewiz
•
Mar 14
Ah, yes, using the .env file makes sense. I've got only one database and so it doesn't matter. But I could see someone using different databases for different purposes (one for day trips, another for hiking?) and so need different maps.
But as I said, while writing it, I decided to move permanently to the mapbox tiles and have made the change on my install.
Say, what and how do you use different databases? Is your installation used by different people?
grantcodes
https://github.com/grantcodes
•
Mar 14
Not exactly an issue but why should the server have the option to only return true / false for the unread count on a channel? Could it not be selected on the client and just use if > 0 logic?
I suppose maybe some servers will only be able to return true / false which makes it easier to build a server...
I'm thinking about using a new Microsub property in the entry to indicate the response URLs that may exist for this post.
{
"type": "entry",
...
"_like": "https://aaronparecki.com/xxxxxxx",
"_repost": "https://aaronparecki.com/yyyyyyyy"
}
alternately:
{
"type": "entry",
...
"_actions": {
"like": "https://aaronparecki.com/xxxxxxx",
"repost": "https://aaronparecki.com/yyyyyyyy"
}
}
For likes and reposts, from a UI perspective, we want to know whether the user has already liked or reposted a post (a boolean yes/no), in order to style the like/repost button differently, so in that case it makes sense to have those be a single string. (The client could send a Micropub delete request with the URL if the user taps the button again, to delete the like/repost.)
For replies, I'm not sure what we actually want the client to indicate. Long-term it would be great if the client had the ability to show the full conversation thread, so in that sense it makes sense to handle replies differently from likes and reposts. Maybe we can handle this question separately for replies.
In the case of likes and reposts, we only care about the URLs of the user's own like/repost posts. Showing other people who have liked or reposted a post is a different problem, since that does not affect the state of the action buttons.
In thinking through this, I'm leaning towards the second JSON option above, nesting the data under _actions, since this data is limited in scope to help indicate the state of the action buttons. It is not meant to cover displaying all responses to a post.
