Skip to content
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

Docs incorrectly display what OperatorFunction extends #6427

Closed
jakovljevic-mladen opened this issue May 26, 2021 · 1 comment · Fixed by #6655
Closed

Docs incorrectly display what OperatorFunction extends #6427

jakovljevic-mladen opened this issue May 26, 2021 · 1 comment · Fixed by #6655
Labels
docs Issues and PRs related to documentation

Comments

@jakovljevic-mladen
Copy link
Member

jakovljevic-mladen commented May 26, 2021

The OperatorFunction docs is having a problem with displaying what the OperatorFunction extends.

The docs state:

interface OperatorFunction<T, R> extends UnaryFunction, Observable> { ...

while it should be:

interface OperatorFunction<T, R> extends UnaryFunction<Observable<T>, Observable<R>> { ...
@cartant cartant added the docs Issues and PRs related to documentation label May 26, 2021
@jakovljevic-mladen
Copy link
Member Author

I did a little research and I think I have found a little closer where the issue might be.

When building the docs (by running npm run docs from the docs_app folder), there are multiple steps involved. One of them is creating this issue, but I'm still not able to investigate how the issue is happening.

The three steps that I narrowed where the issue might be are:

info:    running processor: copyContentAssetsProcessor
info:    running processor: postProcessHtml
info:    running processor: computeSearchTitleProcessor

image

The first and the last (copyContentAssetsProcessor and computeSearchTitleProcessor) are the processors while the second (postProcessHtml) is the post processor and I'm still having issues finding where to put the debugger breakpoint to try to investigate what happens when that one runs. With processors I just had to find the proper file and the proper $process(docs) function so I put breakpoints there. This is what I have found when running the copyContentAssetsProcessor processor function (the one that comes before postProcessHtml):

image

From the image, you can see that the renderedContent is having correct HTML (please note the red outline). But, when the build script continued and when it stopped at the breakpoint in the computeSearchTitleProcessor processor (the one that comes after postProcessHtml), this is what happens:

image

From this image, you can see that postProcessHtml has done something to the content contained in the renderedContent property and that the HTML is quite broken. And such formatted HTML is almost the same one that gets to the docs app and that gets rendered by the browser:
image

Actually, this postProcessHtml step is the one that I was investigation a lot after I said that I will try to add links to the <code> parts of the rendered docs. And I found out that this step is actually adding links (quite successfully) in the Angular project and that it should be doing the same in the RxJS project, but apparently, it is not.

I'd like to get some help from @niklas-wortmann. I wanted to update packages in the docs_app/package.json to try to check if the issue is there because of the old packages. But the issue is that the docs Angular app is still quite old and updating some of the packages require a lot newer versions of Angular and some other libraries. Is there a way to check #5997 and merge it so I could try investigating further.

This postProcessHtml is using quite a lot of external dependencies and since it works in the Angular project and does not in RxJS, the first thing that comes to my mind is to update packages. I will still try to investigate further, but this step might help a lot. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Issues and PRs related to documentation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants