wassname/talk
1
0
Fork 0
mirror of https://github.com/wassname/talk.git synced 2026-07-29 11:28:24 +08:00
Code Issues Packages Projects Releases Wiki Activity

More

Browse Source
This commit is contained in:
okbel
2018-03-22 12:38:33 -03:00
parent 1fc7500837 a4c2b879ea
commit 64094c40db
108 changed files with 1860 additions and 761 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/source/04-06-slots-and-plugins.md
+169
View File
@@ -0,0 +1,169 @@
---
title: Slots and Plugins
permalink: /slots-and-plugins/
---
Plugins make use of **"slots"** in order to change Talk's interface.
By default, Talk has various plugins provided by default. We can see this in `plugins.default.json`:
```json
{
"server": [
"talk-plugin-auth",
"talk-plugin-featured-comments",
"talk-plugin-offtopic",
"talk-plugin-respect"
],
"client": [
"talk-plugin-auth",
"talk-plugin-author-menu",
"talk-plugin-comment-content",
"talk-plugin-featured-comments",
"talk-plugin-flag-details",
"talk-plugin-ignore-user",
"talk-plugin-member-since",
"talk-plugin-moderation-actions",
"talk-plugin-offtopic",
"talk-plugin-permalink",
"talk-plugin-respect",
"talk-plugin-sort-most-replied",
"talk-plugin-sort-most-respected",
"talk-plugin-sort-newest",
"talk-plugin-sort-oldest",
"talk-plugin-viewing-options",
"talk-plugin-profile-settings"
]
}
```
Let's only focus on the plugins which are listed under `client` - these are the plugins that use *slots* to inject certain functionality into the Talk UI.
For example, if we look at the Respect plugin (`talk-plugin-respect`), we can see its `client/index.js` looks like this:
```js
import RespectButton from './RespectButton';
import translations from './translations.yml';
export default {
translations,
slots: {
commentReactions: [RespectButton],
},
};
```
Inside the `slots` property, we specify which **slots** the plugin will use. Above we are saying that the `RespectButton` component is being injected into the slot `commentReactions`.
Slots can receive an Array of components, so we can use one plugin or many for one slot.
### Anatomy of the Slot Component
In Talk core, we have 32 slots available for us to use. The component `Slot` has a `fill` property where we establish the name of the slot. It looks like this:
```js
<Slot
fill="commentReactions"
{...props}
/>
```
You won't have to use this to build plugins, but it's helpful to find where to embed your plugin.
### Slot List
* `adminCommentDetailArea`
* `adminCommentMoreDetails`
* `adminCommentLabels`
* `adminModerationSettings`
* `adminStreamSettings`
* `adminTechSettings`
* `adminCommentInfoBar`
* `adminCommentContent`
* `adminSideActions`
* `adminModeration`
* `adminModerationIndicator`
* `commentInputDetailArea`
* `commentAvatar`
* `commentAuthorName`
* `commentAuthorTags`
* `commentTimestamp`
* `commentInfoBar`
* `commentContent`
* `commentReactions`
* `commentActions`
* `commentInputArea`
* `draftArea`
* `streamSettings`
* `historyCommentTimestamp`
* `profileSections`
* `embed`
* `stream`
* `streamFilter`
* `streamQuestionArea`
* `login`
* `userProfile`
* `userDetailCommentContent`
### Where should I insert my plugin?
The first thing we should consider is what components will be affected by our plugin's functionality. For example, if we want to add functionality to all the comments that are rendered in a total list of comments, we would use the component `Comment`.
The slots that are able to add functionality to comments start with `comment`, like `commentContent`, or `commentReactions`, as you can see above.
### Disabling plugins via `plugins_config`
Typically, you will manage plugins via your `plugins.json` file. If you want to remove a plugin, you would simply delete it there. However, we can also do this directly with the `plugins_config`.
Let's look at our example article, `views/article.ejs`. Here we see we have the Talk embed, and within the embed, we can also send a configuration object. To disable a plugin visually, we can pass `true` to the property `disable_components`. Like so:
```js
plugins_config: {
'talk-plugin-love': {
disable_components: true,
},
}
```
### Sending information to slots and plugins
Inside our `plugins_config`, we can also send properities and our plugins will receive them. For example, if we send this:
```js
plugins_config: {
test: 'data'
}
```
The plugin will receive a config object with the properties we've passed. If we do a `console.log` with `this.props`, we would see:
```js
config: {test: 'data'}
```
### Debugging slots and plugins
You can debug slots and plugins simply by passing the `debug` property with value `true`:
```js
plugins_config: {
debug: true
}
```
This will turn on a visual aid to show you all of Talk's available slots and their names. Just move your mouse around!
### Slot ClassNames
Slots autogenerate their classes with the prefix `talk-slot`, followed by the name of the slot in kebab case.
For example, the class autogenerated for the slot `commentContent` is `talk-slot-comment-content`.
docs/source/05-03-Plugins-API.md → docs/source/04-07-plugins-api.md
+4 -1
View File
@@ -1,4 +1,7 @@
# Plugins API
---
title: Plugins API
permalink: /plugins-api/
---
We created a set of utilities to make it easier to create and add functionality to plugins.
Feel free to check all the utilities here: `talk/plugin-api`.
docs/source/_data/plugins.yml
-4
View File
@@ -13,8 +13,6 @@
- default
- name: talk-plugin-comment-content
description: Linkifies comment content that contains links.
tags:
- default
- name: talk-plugin-deep-reply-count
description: Enables deep reply count graph edge including all decendant replies.
- name: talk-plugin-facebook-auth
@@ -79,8 +77,6 @@
- notifications
- name: talk-plugin-offtopic
description: Allows users to mark a comment as off-topic when they create it.
tags:
- default
- name: talk-plugin-permalink
description: Shows a Link button on comments for direct-linking to a comment.
tags:
docs/source/reference/graphql.md → docs/source/api/graphql.md
+8 -2
View File
@@ -1,9 +1,15 @@
---
title: GraphQL API
permalink: /reference/graphql/
title: GraphQL API Reference
permalink: /api/graphql/
---
We provide all services that Talk can provide via the GraphQL API documented
below. For a primer about GraphQL, visit http://graphql.org/.
If you're already familiar with GraphQL, visit
[GraphQL API Overview](/talk/api/overview/) to see how to
interact with Talk's GraphQL endpoint.
# GraphQL Schema
{% graphqldocs ../../client/coral-framework/graphql/introspection.json %}
docs/source/api/overview.md
+196
View File
@@ -0,0 +1,196 @@
---
title: GraphQL API Overview
permalink: /api/overview/
---
We provide all services that Talk can provide via the GraphQL API documented
on our [GraphQL API Reference](/talk/api/graphql/). If you've never heard
about GraphQL before, visit http://graphql.org/ to learn the basics first.
## Development
During development mode (when Talk has `NODE_ENV=development`) Talk will enable
the GraphiQL IDE at the following route:
${ROOT_URL}api/v1/graph/iql
This is pretty powerful, as it lets you explore the API documentation on the
sidebar as well as send off requests.
## Making your first request
To learn a bit about how to interact with Talk, we'll query for comments on a
page of Talk. I have Talk running locally, (If you don't and want to, checkout
our [Talk Quickstart](/talk/)).
The GraphQL endpoint we have can be used with any HTTP client available, but our
examples below will use the common `curl` tool:
```sh
curl --request POST \
--url http://localhost:3000/api/v1/graph/ql \
--header 'Content-Type: application/json' \
--data '{"query":"query GetComments($url: String!) { asset(url: $url) { title url comments { nodes { body user { username } } } }}","variables":{"url":"http://localhost:3000/"},"operationName":"GetComments"}'
```
When you unpack that, it's really quite simple. We're executing a `POST` request
to the `/api/v1/graph/ql` route of the local Talk server with the GraphQL
request we want to make. It's composed of the `query`, `variables`, and
`operationName`.
```graphql
query GetComments($url: String!) {
asset(url: $url) {
title
url
comments {
nodes {
body
user {
username
}
}
}
}
}
```
The query itself is quite straightforward, we are grabbing the asset with the
specified `$url`, and grabbing it's title and the comments also (You can also
look at our [GraphQL API Reference](/talk/api/graphql/) for our entire schema).
We can then also specify our variables to the query being executed (in this
case, the url for the page where we have comments on our local install of Talk):
```json
{
"url": "http://localhost:3000/"
}
```
It's also sometimes common to have multiple queries within a query, which is
where the `operationName` comes into play, where we simply specify the named
query that we want to execute (in this case, `GetComments`).
To get a deeper understanding of GraphQL queries, read up on
[GraphQL Queries and Mutations](http://graphql.org/learn/queries/).
## Understanding the response
Once you completed the above GraphQL query with `curl`, you'll get a response
sort of like this:
```json
{
"data": {
"asset": {
"title": "Coral Talk",
"url": "http://localhost:3000/",
"comments": {
"nodes": [
{
"body": "Second comment!",
"user": {
"username": "wyattjoh"
}
},
{
"body": "First comment!",
"user": {
"username": "wyattjoh"
}
}
]
}
}
}
}
```
All of the parameters you requested should be available under the `data`
property. Any errors that you get would appear in a `errors` array at the top
level, like this:
```json
{
"data": {
"asset": null
},
"errors": [
{
"message": "asset_url is invalid",
"locations": [
{
"line": 2,
"column": 3
}
],
"path": [
"asset"
]
}
]
}
```
You should know that any property that is marked with a `!` is considered
required, and non-nullable, which means you can always guarantee on it being
there in your request if there were no errors.
## Authorizing a request
Some queries you may notice seem to return `null` or an error of
`NOT_AUTHORIZED`. It's likely the case that you are making a request to a
route that requires authorization. You can perform authorization a few ways in
Talk:
1. As a [Bearer Token](#Bearer-Token)
2. As a [Query Parameter](#Query-Parameter)
3. As a [Cookie](#Cookie)
Essentially, you need to get access to a JWT token that you can use to authorize
your requests. Generating one is simple, you can use the CLI tools in Talk to do
that.
```sh
# first, find your user account
./bin/cli users list
# then, create a token for that account
./bin/cli token create ${USER_ID} example-token
```
Where `USER_ID` is the ID of your user account you found using the `users list`
command.
Once you have your access token, you can substitute it as `${TOKEN}` in your
`curl` request as follows:
### Bearer Token
```sh
curl --request POST \
--url http://localhost:3000/api/v1/graph/ql \
--header 'Content-Type: application/json' \
--header "Authorization: Bearer ${TOKEN}"
--data '{"query":"query GetComments($url: String!) { asset(url: $url) { title url comments { nodes { body user { username } } } }}","variables":{"url":"http://localhost:3000/"},"operationName":"GetComments"}'
```
### Query Parameter
```sh
curl --request POST \
--url http://localhost:3000/api/v1/graph/ql?access_token=${TOKEN} \
--header 'Content-Type: application/json' \
--data '{"query":"query GetComments($url: String!) { asset(url: $url) { title url comments { nodes { body user { username } } } }}","variables":{"url":"http://localhost:3000/"},"operationName":"GetComments"}'
```
### Cookie
```sh
curl --request POST \
--url http://localhost:3000/api/v1/graph/ql \
--header 'Content-Type: application/json' \
--cookie "authorization=${TOKEN}"
--data '{"query":"query GetComments($url: String!) { asset(url: $url) { title url comments { nodes { body user { username } } } }}","variables":{"url":"http://localhost:3000/"},"operationName":"GetComments"}'
```
docs/source/reference/server.md → docs/source/api/server.md
+1 -1
View File
@@ -1,6 +1,6 @@
---
title: Server Plugin API
permalink: /reference/server/
permalink: /api/server/
toc: true
class: configuration
---