[Enhancement]: Componentize readme.md.js file completely

[KunalNasa]

We have componentized only the operations part of readme.md.js file.

Need to break the leftover part into components for better readability.

Also, we have two different components under the components folder of the WebSocket JS client. One for readme file and another for client file. What should the folder hierarchy be?

Should we go with

   components
          |
          |--client
          |      |--client components here
          |
          |-- readme
          |      |-- readme components here

Or is our current structure fine?

[ItshMoh]

Hey @KunalNasa
What i found is that for the README.md part three component files are used which are Availableoperations , MessageExamples and OperationHeader. We can organize them in the proper folder as you have suggested, but to keep in mind that if there will be any common component between client and README.md then what should we do?

[KunalNasa]

Yes @ItshMoh, you are right. There can be similar components between clients and readme files. Also, there is one more problem with this structure: we will be duplicating components of readme from different protocol or language clients.

For example, there can be many components that would be similar for the Python WS readme and the JS WS readme and we don't want to duplicate them.

Therefore, in the last weekly meeting, @derberg suggested finding a solution so that we can put these readme components inside a packages/components folder rather than creating another folder for readme under the websocket/javascript/components folder.

This way we can ensure readme component reusability across different clients of different protocols and languages.

But after going through readme again I found that we can not put all the components of readme inside packages/components as there are so many components in readme that are hard-coded and meant particularly for js ws client and these will be different for different languages and protocols.

So, I am planning to structure it something like this.

• Put reusable readme components inside packages/components folder
• Put readme components specific to client and language inside language/components/readme
• And if there are some components that are shared across readme and client of same language then I believe we would have to make another folder,language/components/common, to keep common components.

So the structure would look something like this.

    |----components
    |           |--- readme
    |                    |--- component-files-here
    |
    |
    |----template/client/websocket
                 |
                 |---- javascript
                            |--- components
                                      |
                                      |--client
                                      |      |--client components here
                                      |
                                      |-- readme
                                      |      |-- readme components here
                                      |
                                      |-- common
                                             |-- common to readme and client of language or protocol 

wdyt about this new structure? 🤔 Please suggest your views @ItshMoh @derberg

[derberg]

packages/components/readme/ makes lots of sense,

might be template/client/websocket/javascript/components/readme/ is not really needed. I bet that once all components are created, we will see all are reusable and you will endup having a very lightweight template file template/client/websocket/javascript/components/readme.js with only few components from packages/components/readme/ integrated

[KunalNasa]

@derberg , you mean we should make reusable readme components for all clients and put them in packages/components/readme for reusability. And those components that are particular to readme files on particular client should stay in readme.md.js file as they are, and we don't need to componentize them in a separate folder (eg. template/client/websocket/javascript/components/readme) as it would be a very lightweight folder with very few components?

[derberg]

yup, in theory majority of readme files, for clients for any protocol, will be looking almost the same, with the same headings, etc, so having them in packages/components/readme is best.

to be honest, I think we should do it with majority of components, and have componend for example for rendering JS methods and PY methods, and use it the same way we have Models components, where you use the component and pass props with info what programming language you want in output - but year, separate story

[thulieblack]

I'll be working on this issue.