-
Notifications
You must be signed in to change notification settings - Fork 399
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix #943: Incorporate Socket Mode as default for Getting Started guide #990
Fix #943: Incorporate Socket Mode as default for Getting Started guide #990
Conversation
Codecov Report
@@ Coverage Diff @@
## main #990 +/- ##
=======================================
Coverage 66.41% 66.41%
=======================================
Files 13 13
Lines 1212 1212
Branches 357 357
=======================================
Hits 805 805
Misses 338 338
Partials 69 69 Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I opted to keep the Tokens and installing apps
, and Setting up your project
sections pretty much the same content-wise, since adding a ton of context around communication protocols right at the outset seemed intimidating. There are already several concepts being covered there. Instead, most of the context-setting around Socket Mode (vs. HTTP) I added to the the Setting up events
section, since that is where the communication protocol really becomes relevant (from a conceptual standpoint).
Also thought that having the user do the basic setup in their project (without setting SocketMode or app token options) and then return back to add them as part of enabling Socket Mode might help with their learning about what's required and not.
Would love to know if folks think this strikes a good balance between accessibility (getting to Hello World faster) and informativeness (why Socket Mode for getting started, what are alternatives), and what improvements we can make if not!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These changes look great, and thanks for cleaning up spelling and grammar errors. I've Included some suggestions and thoughts—feel free to ignore the ones you don't agree with 😄
Add link Co-authored-by: Shay DeWael <swdewael@gmail.com>
Add bot link Co-authored-by: Shay DeWael <swdewael@gmail.com>
Remove basic Co-authored-by: Shay DeWael <swdewael@gmail.com>
…iang/bolt-js into sj-issue-943-update-getting-started
Co-authored-by: Shay DeWael <swdewael@gmail.com>
Co-authored-by: Shay DeWael <swdewael@gmail.com>
…iang/bolt-js into sj-issue-943-update-getting-started
Co-authored-by: Shay DeWael <swdewael@gmail.com>
Co-authored-by: Shay DeWael <swdewael@gmail.com>
…iang/bolt-js into sj-issue-943-update-getting-started
Co-authored-by: Shay DeWael <swdewael@gmail.com>
Co-authored-by: Shay DeWael <swdewael@gmail.com>
Co-authored-by: Shay DeWael <swdewael@gmail.com>
Change to app-level token Co-authored-by: Kazuhiro Sera <seratch@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work @srajiang!!
I've left a bit of feedback.
In terms of preserving http/ngrok steps, I think we should create a copy of the original getting started guide and name it something like Getting started with http
or via http? It can live in the side menu near the bottom with the other guides. Then we can link to the http version in blurbs throughout this guide. This way, we provide multiple entry points to the http version of the guide, but don't need to mix in no socket mode content into this one. Thoughts @shaydewael?
docs/_tutorials/getting_started.md
Outdated
|
||
> ⚙️We've collected some of the most common hosting providers Slack developers use to host their apps [on our API site](https://api.slack.com/docs/hosting) | ||
> 💡 Socket Mode allows apps to use the Events API and interactive components without exposing a public HTTP endpoint. This can be helpful during development, or if you're receiving requests from behind a firewall. HTTP is more useful for apps being deployed to hosting environments (like [AWS](/bolt-js/deployments/aws-lambda) or [Heroku](/bolt-js/deployments/heroku)), or apps intended for distribution. You can easily toggle between Socket Mode and HTTP connections at any time in the app config. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be good to add a blurb in this section about checking out the http getting started guide (assuming we go with the two guide approach).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I've added some specific language to allow the user to "fork" into the alternate guide :)
docs/_tutorials/getting_started.md
Outdated
There are three main token types available to a Slack app: user (`xoxp`), bot (`xoxb`), and app (`xapp`) tokens. | ||
- [User tokens](https://api.slack.com/authentication/token-types#user) allow you to call API methods on behalf of users after they install or authenticate the app. There may be several user tokens for a single workspace. | ||
- [Bot tokens](https://api.slack.com/authentication/token-types#bot) are associated with bot users, and are only granted once in a workspace where someone installs the app. The bot token your app uses will be the same no matter which user performed the installation. Bot tokens are the token type that _most_ apps use. | ||
- [App-level tokens](https://api.slack.com/authentication/token-types#app) represent your app across organizations, including installations by all individual users on all workspaces in a given organization. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could possibly mention that app-level tokens are commonly used for creating a websocket connection to the app
@@ -79,13 +81,13 @@ export SLACK_SIGNING_SECRET=<your-signing-secret> | |||
export SLACK_BOT_TOKEN=xoxb-<your-bot-token> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For this guide, users will need both bot token and app-level token. App-level token for starting socket mode, bot token for interacting with the slack api. I agree that holding off introducing app-level-token until the socket mode section makes sense
docs/_tutorials/getting_started.md
Outdated
@@ -323,4 +330,4 @@ Now that you have a basic app up and running, you can start exploring how to mak | |||
|
|||
* Bolt allows you to [call Web API methods](/bolt-js/concepts#web-api) with the client attached to your app. There are [over 220 methods](https://api.slack.com/methods) on our API site. | |||
|
|||
* Learn more about the different token types [on our API site](https://api.slack.com/docs/token-types). Your app may need different tokens depending on the actions you want it to perform. | |||
* Learn more about the different token types [on our API site](https://api.slack.com/docs/token-types). Your app may need different tokens depending on the actions you want it to perform. For apps that do not use Socket Mode, typically only a bot (`xoxb`) token is required. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another good place to link http getting started guide.
Co-authored-by: Steve Gill <stevengill97@gmail.com>
…iang/bolt-js into sj-issue-943-update-getting-started
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In terms of preserving http/ngrok steps, I think we should create a copy of the original getting started guide and name it something like
Getting started with http
or via http? It can live in the side menu near the bottom with the other guides. Then we can link to the http version in blurbs throughout this guide. This way, we provide multiple entry points to the http version of the guide, but don't need to mix in no socket mode content into this one. Thoughts @shaydewael?
I've pushed some changes in line with this approach ☝️ and included a blurb that allows the reader to sort of "fork" into HTTP / Request URl setup in the "Setting up events" section . @stevengill @shaydewael what do we think? Will it work? 🙇♀️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Can you convert this to a regular PR so we can let the checks run. If all looks good, merge away!
Great work!!
Summary
Based on issue #943, this PR is a first stab at updating our Bolt for JS Getting Started guides to Socket Mode as default.
The motivation for making this change is to mitigate the common pain-points of setting up a static HTTP Request endpoint configuration (ngrok), and configuring those URLs in the various surfaces within app config.
Changes
getting_started.md
and removes HTTP / Request URL-specific setupgetting_started_http.md
guide which is parallel to to the standard guide, located down below with the rest of tutorials, which retains instructions specific to setting up with HTTP.Testing
/docs/ and
bundle exec jekyll serve` to build the pages locally. I found this helpful to check how formatting was applying.Requirements (place an
x
in each[ ]
)