Mirror
/
zulip
mirror of https://github.com/zulip/zulip.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
zulip/static/js/markdown_config.js

49 lines
1.6 KiB
JavaScript
Raw Normal View History

js: Convert static/js/hash_util.js to ES6 module. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-02-28 01:07:13 +01:00
import * as hash_util from "./hash_util";
js: Convert static/js/markdown_config.js to ES6 module. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-02-10 17:12:28 +01:00
import * as people from "./people";
js: Convert static/js/stream_data.js to ES6 module. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-02-28 00:53:59 +01:00
import * as stream_data from "./stream_data";
js: Convert static/js/user_groups.js to ES6 module. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-02-28 00:42:57 +01:00
import * as user_groups from "./user_groups";
frontend: Add new user_settings module for user's settings. We add a new user_settings module similar to page_params module in frontend and use it to access user's personal settings instead of page_params.
2021-07-28 16:00:58 +02:00
import {user_settings} from "./user_settings";
js: Purge people module from window.
2020-08-20 21:24:06 +02:00
markdown: Add helper configuration for mobile. This refactoring is the first step toward sharing our markdown code with mobile. This focuses on the Zulip layer, not the underlying third party `marked` library. In this commit we do a one-time initialization to wire up the markdown functions, but after further discussions with Greg, it might make more sense to just pass in helpers on every use of markdown (which is generally only once per sent message). I'll address that in follow-up commits. Even though it looks like a pretty invasive change, you will note that we barely needed to modify the node tests to make this pass. And we have pretty decent test coverage here. All of the places where we used to depend on other Zulip modules now use helper functions that any client (e.g. mobile) can configure themselves. Or course, in the webapp, we configure these from modules like people/stream_data/hash_util/etc. Even in places where markdown used to deal directly with data structures from other modules, we now use functions. We may revisit this in a future commit, and we might just pass data directly for certain things. I decided to keep the helpers data structure completely flat, so we don't have ugly nested names like `helpers.emoji.get_emoji_codepoint`. Because of this, some of the names aren't 1:1, which I think is fine. For example, we map `user_groups.is_member_of` to `is_member_of_user_group`. It's likely that mobile already has different names for their versions of these functions, so trying for fake consistency would only help the webapp. In some cases, I think the webapp functions have names that could be improved, but we can clean that up in future commits, and since the names aren't coupled to markdown itself (i.e. only the config), we will be less constrained. It's worth noting that `marked` has an `options` data structure that it uses for configuration, but I didn't piggyback onto it, since the `marked` options are more at the lexing/parsing layer vs. the app-data layer stuff that our helpers mostly help with. Hopefully it's obvious why I just put helpers in the top-level namespace for the module rather than passing it around through multiple layers of the parser. There were a couple places in markdown where we were doing awkward `hasOwnProperty` checks for emoji-related stuff. Now we use the Python principle of ask-forgiveness-not-permission and just handle the getters returning falsy data. (It should be `undefined`, but any falsy value is unworkable in the places I changed, so I use the simpler, less brittle form.) We also break our direct dependency on `emoji_codes.json` (with some help from the prior commit). In one place I rename streamName to stream_name, fixing up an ancient naming violation that goes way back to before this code was even extracted away from echo.js. I didn't bother to split this out into a separate commit, since 2 of the 4 lines would be immediately re-modified in the subsequent commit. Note that we still depend on `fenced_code` via the global namespace, instead of simply requiring it directly or injecting it. The reason I'm postponing any action there is that we'll have to change things once we move markdown into a shared library. (The most likely outcome is that we'll rename/move both files at the same time and fix the namespace/require details as part of that commit.) Also the markdown code still relies on `_` being available in the global namespace. We aren't quite ready to share code with mobile yet, but the underscore dependency should not be problematic, since mobile already uses underscore to use the webapp's shared typing_status module.
2020-02-13 13:54:11 +01:00
/*
This config is in a separate file for partly
docs: Correct “webapp” to “web app”. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-05-14 00:16:30 +02:00
tactical reasons. We want the web app to
markdown: Add helper configuration for mobile. This refactoring is the first step toward sharing our markdown code with mobile. This focuses on the Zulip layer, not the underlying third party `marked` library. In this commit we do a one-time initialization to wire up the markdown functions, but after further discussions with Greg, it might make more sense to just pass in helpers on every use of markdown (which is generally only once per sent message). I'll address that in follow-up commits. Even though it looks like a pretty invasive change, you will note that we barely needed to modify the node tests to make this pass. And we have pretty decent test coverage here. All of the places where we used to depend on other Zulip modules now use helper functions that any client (e.g. mobile) can configure themselves. Or course, in the webapp, we configure these from modules like people/stream_data/hash_util/etc. Even in places where markdown used to deal directly with data structures from other modules, we now use functions. We may revisit this in a future commit, and we might just pass data directly for certain things. I decided to keep the helpers data structure completely flat, so we don't have ugly nested names like `helpers.emoji.get_emoji_codepoint`. Because of this, some of the names aren't 1:1, which I think is fine. For example, we map `user_groups.is_member_of` to `is_member_of_user_group`. It's likely that mobile already has different names for their versions of these functions, so trying for fake consistency would only help the webapp. In some cases, I think the webapp functions have names that could be improved, but we can clean that up in future commits, and since the names aren't coupled to markdown itself (i.e. only the config), we will be less constrained. It's worth noting that `marked` has an `options` data structure that it uses for configuration, but I didn't piggyback onto it, since the `marked` options are more at the lexing/parsing layer vs. the app-data layer stuff that our helpers mostly help with. Hopefully it's obvious why I just put helpers in the top-level namespace for the module rather than passing it around through multiple layers of the parser. There were a couple places in markdown where we were doing awkward `hasOwnProperty` checks for emoji-related stuff. Now we use the Python principle of ask-forgiveness-not-permission and just handle the getters returning falsy data. (It should be `undefined`, but any falsy value is unworkable in the places I changed, so I use the simpler, less brittle form.) We also break our direct dependency on `emoji_codes.json` (with some help from the prior commit). In one place I rename streamName to stream_name, fixing up an ancient naming violation that goes way back to before this code was even extracted away from echo.js. I didn't bother to split this out into a separate commit, since 2 of the 4 lines would be immediately re-modified in the subsequent commit. Note that we still depend on `fenced_code` via the global namespace, instead of simply requiring it directly or injecting it. The reason I'm postponing any action there is that we'll have to change things once we move markdown into a shared library. (The most likely outcome is that we'll rename/move both files at the same time and fix the namespace/require details as part of that commit.) Also the markdown code still relies on `_` being available in the global namespace. We aren't quite ready to share code with mobile yet, but the underscore dependency should not be problematic, since mobile already uses underscore to use the webapp's shared typing_status module.
2020-02-13 13:54:11 +01:00
configure this one way, but we don't want to
share this code with mobile.
I also wanted to make some diffs clear before
doing any major file moves.
docs: Capitalize Markdown consistently. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2020-08-11 01:47:49 +02:00
Also, I want the unit tests for Markdown to
markdown: Add helper configuration for mobile. This refactoring is the first step toward sharing our markdown code with mobile. This focuses on the Zulip layer, not the underlying third party `marked` library. In this commit we do a one-time initialization to wire up the markdown functions, but after further discussions with Greg, it might make more sense to just pass in helpers on every use of markdown (which is generally only once per sent message). I'll address that in follow-up commits. Even though it looks like a pretty invasive change, you will note that we barely needed to modify the node tests to make this pass. And we have pretty decent test coverage here. All of the places where we used to depend on other Zulip modules now use helper functions that any client (e.g. mobile) can configure themselves. Or course, in the webapp, we configure these from modules like people/stream_data/hash_util/etc. Even in places where markdown used to deal directly with data structures from other modules, we now use functions. We may revisit this in a future commit, and we might just pass data directly for certain things. I decided to keep the helpers data structure completely flat, so we don't have ugly nested names like `helpers.emoji.get_emoji_codepoint`. Because of this, some of the names aren't 1:1, which I think is fine. For example, we map `user_groups.is_member_of` to `is_member_of_user_group`. It's likely that mobile already has different names for their versions of these functions, so trying for fake consistency would only help the webapp. In some cases, I think the webapp functions have names that could be improved, but we can clean that up in future commits, and since the names aren't coupled to markdown itself (i.e. only the config), we will be less constrained. It's worth noting that `marked` has an `options` data structure that it uses for configuration, but I didn't piggyback onto it, since the `marked` options are more at the lexing/parsing layer vs. the app-data layer stuff that our helpers mostly help with. Hopefully it's obvious why I just put helpers in the top-level namespace for the module rather than passing it around through multiple layers of the parser. There were a couple places in markdown where we were doing awkward `hasOwnProperty` checks for emoji-related stuff. Now we use the Python principle of ask-forgiveness-not-permission and just handle the getters returning falsy data. (It should be `undefined`, but any falsy value is unworkable in the places I changed, so I use the simpler, less brittle form.) We also break our direct dependency on `emoji_codes.json` (with some help from the prior commit). In one place I rename streamName to stream_name, fixing up an ancient naming violation that goes way back to before this code was even extracted away from echo.js. I didn't bother to split this out into a separate commit, since 2 of the 4 lines would be immediately re-modified in the subsequent commit. Note that we still depend on `fenced_code` via the global namespace, instead of simply requiring it directly or injecting it. The reason I'm postponing any action there is that we'll have to change things once we move markdown into a shared library. (The most likely outcome is that we'll rename/move both files at the same time and fix the namespace/require details as part of that commit.) Also the markdown code still relies on `_` being available in the global namespace. We aren't quite ready to share code with mobile yet, but the underscore dependency should not be problematic, since mobile already uses underscore to use the webapp's shared typing_status module.
2020-02-13 13:54:11 +01:00
be able to reuse this code easily (and therefore
didn't just put this in ui_init.js).
docs: Capitalize Markdown consistently. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2020-08-11 01:47:49 +02:00
Once the first steps of making Markdown be a
markdown: Add helper configuration for mobile. This refactoring is the first step toward sharing our markdown code with mobile. This focuses on the Zulip layer, not the underlying third party `marked` library. In this commit we do a one-time initialization to wire up the markdown functions, but after further discussions with Greg, it might make more sense to just pass in helpers on every use of markdown (which is generally only once per sent message). I'll address that in follow-up commits. Even though it looks like a pretty invasive change, you will note that we barely needed to modify the node tests to make this pass. And we have pretty decent test coverage here. All of the places where we used to depend on other Zulip modules now use helper functions that any client (e.g. mobile) can configure themselves. Or course, in the webapp, we configure these from modules like people/stream_data/hash_util/etc. Even in places where markdown used to deal directly with data structures from other modules, we now use functions. We may revisit this in a future commit, and we might just pass data directly for certain things. I decided to keep the helpers data structure completely flat, so we don't have ugly nested names like `helpers.emoji.get_emoji_codepoint`. Because of this, some of the names aren't 1:1, which I think is fine. For example, we map `user_groups.is_member_of` to `is_member_of_user_group`. It's likely that mobile already has different names for their versions of these functions, so trying for fake consistency would only help the webapp. In some cases, I think the webapp functions have names that could be improved, but we can clean that up in future commits, and since the names aren't coupled to markdown itself (i.e. only the config), we will be less constrained. It's worth noting that `marked` has an `options` data structure that it uses for configuration, but I didn't piggyback onto it, since the `marked` options are more at the lexing/parsing layer vs. the app-data layer stuff that our helpers mostly help with. Hopefully it's obvious why I just put helpers in the top-level namespace for the module rather than passing it around through multiple layers of the parser. There were a couple places in markdown where we were doing awkward `hasOwnProperty` checks for emoji-related stuff. Now we use the Python principle of ask-forgiveness-not-permission and just handle the getters returning falsy data. (It should be `undefined`, but any falsy value is unworkable in the places I changed, so I use the simpler, less brittle form.) We also break our direct dependency on `emoji_codes.json` (with some help from the prior commit). In one place I rename streamName to stream_name, fixing up an ancient naming violation that goes way back to before this code was even extracted away from echo.js. I didn't bother to split this out into a separate commit, since 2 of the 4 lines would be immediately re-modified in the subsequent commit. Note that we still depend on `fenced_code` via the global namespace, instead of simply requiring it directly or injecting it. The reason I'm postponing any action there is that we'll have to change things once we move markdown into a shared library. (The most likely outcome is that we'll rename/move both files at the same time and fix the namespace/require details as part of that commit.) Also the markdown code still relies on `_` being available in the global namespace. We aren't quite ready to share code with mobile yet, but the underscore dependency should not be problematic, since mobile already uses underscore to use the webapp's shared typing_status module.
2020-02-13 13:54:11 +01:00
shared library are complete, we may tweak
the file organization a bit.
Most functions here that are looking up data
follow the convention of returning `undefined`
when the lookups fail.
*/
js: Convert static/js/markdown_config.js to ES6 module. Signed-off-by: Anders Kaseorg <anders@zulip.com>
2021-02-10 17:12:28 +01:00
export const get_helpers = () => ({
markdown: Add helper configuration for mobile. This refactoring is the first step toward sharing our markdown code with mobile. This focuses on the Zulip layer, not the underlying third party `marked` library. In this commit we do a one-time initialization to wire up the markdown functions, but after further discussions with Greg, it might make more sense to just pass in helpers on every use of markdown (which is generally only once per sent message). I'll address that in follow-up commits. Even though it looks like a pretty invasive change, you will note that we barely needed to modify the node tests to make this pass. And we have pretty decent test coverage here. All of the places where we used to depend on other Zulip modules now use helper functions that any client (e.g. mobile) can configure themselves. Or course, in the webapp, we configure these from modules like people/stream_data/hash_util/etc. Even in places where markdown used to deal directly with data structures from other modules, we now use functions. We may revisit this in a future commit, and we might just pass data directly for certain things. I decided to keep the helpers data structure completely flat, so we don't have ugly nested names like `helpers.emoji.get_emoji_codepoint`. Because of this, some of the names aren't 1:1, which I think is fine. For example, we map `user_groups.is_member_of` to `is_member_of_user_group`. It's likely that mobile already has different names for their versions of these functions, so trying for fake consistency would only help the webapp. In some cases, I think the webapp functions have names that could be improved, but we can clean that up in future commits, and since the names aren't coupled to markdown itself (i.e. only the config), we will be less constrained. It's worth noting that `marked` has an `options` data structure that it uses for configuration, but I didn't piggyback onto it, since the `marked` options are more at the lexing/parsing layer vs. the app-data layer stuff that our helpers mostly help with. Hopefully it's obvious why I just put helpers in the top-level namespace for the module rather than passing it around through multiple layers of the parser. There were a couple places in markdown where we were doing awkward `hasOwnProperty` checks for emoji-related stuff. Now we use the Python principle of ask-forgiveness-not-permission and just handle the getters returning falsy data. (It should be `undefined`, but any falsy value is unworkable in the places I changed, so I use the simpler, less brittle form.) We also break our direct dependency on `emoji_codes.json` (with some help from the prior commit). In one place I rename streamName to stream_name, fixing up an ancient naming violation that goes way back to before this code was even extracted away from echo.js. I didn't bother to split this out into a separate commit, since 2 of the 4 lines would be immediately re-modified in the subsequent commit. Note that we still depend on `fenced_code` via the global namespace, instead of simply requiring it directly or injecting it. The reason I'm postponing any action there is that we'll have to change things once we move markdown into a shared library. (The most likely outcome is that we'll rename/move both files at the same time and fix the namespace/require details as part of that commit.) Also the markdown code still relies on `_` being available in the global namespace. We aren't quite ready to share code with mobile yet, but the underscore dependency should not be problematic, since mobile already uses underscore to use the webapp's shared typing_status module.
2020-02-13 13:54:11 +01:00
// user stuff
get_actual_name_from_user_id: people.get_actual_name_from_user_id,
get_user_id_from_name: people.get_user_id_from_name,
is_valid_full_name_and_user_id: people.is_valid_full_name_and_user_id,
my_user_id: people.my_current_user_id,
markdown: Extend user mention syntax to support user_id for mentioning. Extend our markdown system to support mentioning of users by id also. Following these changes, it would be possible to mention users with @**|user_id** and silently mention using @_**|user_id**. Main intention for extending the mention syntax is to make it convenient for bots to mention a users using their ids. It is to be noted that previous syntax are also supported. Documentation tweaked by tabbott for better readability. The changes were tested manually in development server, and also by adding some new backend and frontend tests. Fixes: #17487.
2021-03-23 20:22:04 +01:00
is_valid_user_id: people.is_known_user_id,
markdown: Add helper configuration for mobile. This refactoring is the first step toward sharing our markdown code with mobile. This focuses on the Zulip layer, not the underlying third party `marked` library. In this commit we do a one-time initialization to wire up the markdown functions, but after further discussions with Greg, it might make more sense to just pass in helpers on every use of markdown (which is generally only once per sent message). I'll address that in follow-up commits. Even though it looks like a pretty invasive change, you will note that we barely needed to modify the node tests to make this pass. And we have pretty decent test coverage here. All of the places where we used to depend on other Zulip modules now use helper functions that any client (e.g. mobile) can configure themselves. Or course, in the webapp, we configure these from modules like people/stream_data/hash_util/etc. Even in places where markdown used to deal directly with data structures from other modules, we now use functions. We may revisit this in a future commit, and we might just pass data directly for certain things. I decided to keep the helpers data structure completely flat, so we don't have ugly nested names like `helpers.emoji.get_emoji_codepoint`. Because of this, some of the names aren't 1:1, which I think is fine. For example, we map `user_groups.is_member_of` to `is_member_of_user_group`. It's likely that mobile already has different names for their versions of these functions, so trying for fake consistency would only help the webapp. In some cases, I think the webapp functions have names that could be improved, but we can clean that up in future commits, and since the names aren't coupled to markdown itself (i.e. only the config), we will be less constrained. It's worth noting that `marked` has an `options` data structure that it uses for configuration, but I didn't piggyback onto it, since the `marked` options are more at the lexing/parsing layer vs. the app-data layer stuff that our helpers mostly help with. Hopefully it's obvious why I just put helpers in the top-level namespace for the module rather than passing it around through multiple layers of the parser. There were a couple places in markdown where we were doing awkward `hasOwnProperty` checks for emoji-related stuff. Now we use the Python principle of ask-forgiveness-not-permission and just handle the getters returning falsy data. (It should be `undefined`, but any falsy value is unworkable in the places I changed, so I use the simpler, less brittle form.) We also break our direct dependency on `emoji_codes.json` (with some help from the prior commit). In one place I rename streamName to stream_name, fixing up an ancient naming violation that goes way back to before this code was even extracted away from echo.js. I didn't bother to split this out into a separate commit, since 2 of the 4 lines would be immediately re-modified in the subsequent commit. Note that we still depend on `fenced_code` via the global namespace, instead of simply requiring it directly or injecting it. The reason I'm postponing any action there is that we'll have to change things once we move markdown into a shared library. (The most likely outcome is that we'll rename/move both files at the same time and fix the namespace/require details as part of that commit.) Also the markdown code still relies on `_` being available in the global namespace. We aren't quite ready to share code with mobile yet, but the underscore dependency should not be problematic, since mobile already uses underscore to use the webapp's shared typing_status module.
2020-02-13 13:54:11 +01:00
// user groups
get_user_group_from_name: user_groups.get_user_group_from_name,
is_member_of_user_group: user_groups.is_member_of,
// stream hashes
get_stream_by_name: stream_data.get_sub,
stream_hash: hash_util.by_stream_uri,
stream_topic_hash: hash_util.by_stream_topic_uri,
// settings
frontend: Add new user_settings module for user's settings. We add a new user_settings module similar to page_params module in frontend and use it to access user's personal settings instead of page_params.
2021-07-28 16:00:58 +02:00
should_translate_emoticons: () => user_settings.translate_emoticons,
markdown: Add helper configuration for mobile. This refactoring is the first step toward sharing our markdown code with mobile. This focuses on the Zulip layer, not the underlying third party `marked` library. In this commit we do a one-time initialization to wire up the markdown functions, but after further discussions with Greg, it might make more sense to just pass in helpers on every use of markdown (which is generally only once per sent message). I'll address that in follow-up commits. Even though it looks like a pretty invasive change, you will note that we barely needed to modify the node tests to make this pass. And we have pretty decent test coverage here. All of the places where we used to depend on other Zulip modules now use helper functions that any client (e.g. mobile) can configure themselves. Or course, in the webapp, we configure these from modules like people/stream_data/hash_util/etc. Even in places where markdown used to deal directly with data structures from other modules, we now use functions. We may revisit this in a future commit, and we might just pass data directly for certain things. I decided to keep the helpers data structure completely flat, so we don't have ugly nested names like `helpers.emoji.get_emoji_codepoint`. Because of this, some of the names aren't 1:1, which I think is fine. For example, we map `user_groups.is_member_of` to `is_member_of_user_group`. It's likely that mobile already has different names for their versions of these functions, so trying for fake consistency would only help the webapp. In some cases, I think the webapp functions have names that could be improved, but we can clean that up in future commits, and since the names aren't coupled to markdown itself (i.e. only the config), we will be less constrained. It's worth noting that `marked` has an `options` data structure that it uses for configuration, but I didn't piggyback onto it, since the `marked` options are more at the lexing/parsing layer vs. the app-data layer stuff that our helpers mostly help with. Hopefully it's obvious why I just put helpers in the top-level namespace for the module rather than passing it around through multiple layers of the parser. There were a couple places in markdown where we were doing awkward `hasOwnProperty` checks for emoji-related stuff. Now we use the Python principle of ask-forgiveness-not-permission and just handle the getters returning falsy data. (It should be `undefined`, but any falsy value is unworkable in the places I changed, so I use the simpler, less brittle form.) We also break our direct dependency on `emoji_codes.json` (with some help from the prior commit). In one place I rename streamName to stream_name, fixing up an ancient naming violation that goes way back to before this code was even extracted away from echo.js. I didn't bother to split this out into a separate commit, since 2 of the 4 lines would be immediately re-modified in the subsequent commit. Note that we still depend on `fenced_code` via the global namespace, instead of simply requiring it directly or injecting it. The reason I'm postponing any action there is that we'll have to change things once we move markdown into a shared library. (The most likely outcome is that we'll rename/move both files at the same time and fix the namespace/require details as part of that commit.) Also the markdown code still relies on `_` being available in the global namespace. We aren't quite ready to share code with mobile yet, but the underscore dependency should not be problematic, since mobile already uses underscore to use the webapp's shared typing_status module.
2020-02-13 13:54:11 +01:00
});