refactor(TextFormatter): create TextFormatter component TASK-996

[pauloamorimbr]

🗒️ Checklist

1. run linter locally
2. update all related docs (API, README, inline, etc.), if any
3. draft PR with a title <type>(<scope>)<!>: <title> TASK-1234
4. tag PR: at least frontend or backend unless it's global
5. fill in the template below and delete template comments
6. review thyself: read the diff and repro the preview as written
7. open PR & confirm that CI passes
8. request reviewers, if needed
9. delete this section before merging

👀 Preview steps

• The component is available for visualization and tests in storybook

💭 Notes

A TextFormatter component is being added to support long strings formatted in a markdown-like fashion.
Such component is needed to support long sentences to be properly translated without having to break out words just to add simple styles like bold, italic or links.

• The TextFormatter component suports an input of a text prop containing an string to be processed and generates the output based on the processing of the string.
• Formatting can be nested if needed

[jamesrkiger]

Just a style issue, but we generally like to avoid if/else chains in favor of multiple simple if statements:

if (x) {
    return a
}
if (y) {
    return b
}
return c

[jamesrkiger]

Left one minor comment, but other than that lgtm.

[magicznyleszek]

@pauloamorimbr do we have plans to use it in all the places that currently go with dangerouslySetInnerHTML? I think there are around 11 of them (and not all apply).

The list of components that could use TextFormatter:

• ActivityMessage
• SharingForm (uses replaceBracketsWithLink)
• TransferProjects
• AccessDenied (uses replaceBracketsWithLink)
• UniversalTable

Also do we have plans to replace our old way of handling links (replaceBracketsWithLink from textUtils.ts) with this new way? :) Not sure if these two are really compatible, as replaceBracketsWithLink has a bit different functionality (there is no URL in the translation string, e.g. foo [link] bar, FE code provides the link) - but I think at least we should acknowledge one and the other with a comment. I haven't looked too deep into this :P

[magicznyleszek]

Also I think that this should be discussed with @JacquelineMorrissette (unless it already was) given the fact that we are kinda setting some new rules for how translation text is written.

[magicznyleszek]

Wouldn't some existing library satisfy our needs here? Like https://www.npmjs.com/package/markdown-to-jsx or https://www.npmjs.com/package/react-markdown or https://www.npmjs.com/package/marked ?

[Akuukis]

I've used react-markdown before and suggest it. I like most the ability to override all components with custom implementation, that's useful especially with Link-s.

[pauloamorimbr]

Since the need here was a simple subset of what markdown does I opted not to use a full library, not at first at least, so we wouldn't have to worry about unwanted markdown styles being accidentally inserted in string and also implementing it simply would avoid having another library linked to the project, but after talking to @Akuukis about this I ended up agreeing that using a library would simplify things here, mainly because there are libraries where we can opt for which marks we want to implement.

[pauloamorimbr]

Also I think that this should be discussed with @JacquelineMorrissette (unless it already was) given the fact that we are kinda setting some new rules for how translation text is written.

I did talk to @JacquelineMorrissette about this. 👍🏻

[pauloamorimbr]

@pauloamorimbr do we have plans to use it in all the places that currently go with dangerouslySetInnerHTML? I think there are around 11 of them (and not all apply).

The list of components that could use TextFormatter:

• ActivityMessage
• SharingForm (uses replaceBracketsWithLink)
• TransferProjects
• AccessDenied (uses replaceBracketsWithLink)
• UniversalTable

Also do we have plans to replace our old way of handling links (replaceBracketsWithLink from textUtils.ts) with this new way? :) Not sure if these two are really compatible, as replaceBracketsWithLink has a bit different functionality (there is no URL in the translation string, e.g. foo [link] bar, FE code provides the link) - but I think at least we should acknowledge one and the other with a comment. I haven't looked too deep into this :P

I didn't think of migrating other stuff. The idea is to apply this to the changes I'm working on right now.
If you think we could benefit from applying the same to other pieces of code I believe we could create another task to handle that. WDYT?

Regarding replacing the replaceBracketsWithLink, using markdown allow us to have better text for translation. I've taken a look at it and it's not exactly the same. I believe it falls in the same answer as above. We could create a new task to refactor what's being done currently.
I didn't consider using HTML directly due to safety reasons and also because it's a less recognizable text for translatos...that's why I'm suggesting the new approach.

[pauloamorimbr]

I've done tests with the react-markdown and it seems to work pretty well. For now I don't think we will benefit from wrapping it in our own component, so I will close this PR if no one disagrees in favor of just using the react-markdown on #5249 directly.

[magicznyleszek]

@pauloamorimbr made a task for the refactor proposition: https://www.notion.so/kobotoolbox/Refactor-some-dangerouslySetInnerHTML-code-to-use-react-markdown-13e7e515f65480c5a95ec9b1a7a7477c?pvs=4

[pauloamorimbr]

Thanks. I'm mentioning this in the other PR.