1 Commits

Author	SHA1	Message	Date
Steve Howell	b55d2bc256	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-18 16:13:38 -08:00