Feedback and suggestions for documentation, PR#76

[AlveinTeng]

I have been reviewing the current documentation #76 and would like to propose some enhancements that I believe will improve its comprehensiveness and usability.

Proposed Enhancements:

Overview of Encre's Overall Design:

• Add a detailed explanation of Encre's overall design.
• Include a high-level overview of the architecture.
• Provide a structural diagram to illustrate the interaction between various components.

Comprehensive Explanation of Core Elements:

• Add more detailed explanations for fundamental elements, such as callables.
• Include definitions and roles of these elements within the system.( Why we have such design)

[Ikochoy]

File 1: http://localhost:3000/docs/api/core/events/input/transform/splitter

• Problem: It was quite confusing to have multiple Typeparam and Type Parameters headings, as if they are referring to same thing. If my understanding is right, each of CallInput, CallOutput, and CallOptions are independent classes. For the image below, may I assume that Context, ContextLike etc are children of the above classes. I think it would be more helpful to have a brief description of the relationship between the type parameters.

  

• suggestion: better order methods name using ascending order so that it will be easier for users to find/navigate

• suggestion: Under Implementation of the [ContextSplitterParams], would it be better to specify the methods that we must implements?

• not sure whether it is common practise to include what classes are extending a working class

File 2: http://localhost:3000/docs/api/core/events/output/provide/base/

• Is there a particular reason why we are using the word 'source' rather than 'input'

  

• How many options do we have T, can we fit every class in?

• For documentation like this, would you prefer to include the parameter name or the paramter type in the documentation.

  

• Suggestion: Like what Alvein suggest on top, i recommend to have a relationship chart for each directory between classes and the interfaces in the directory.

[VictorS67]

This documentation is generated by TypeDoc from the code documentation in the files. If you want to add higher-level concept explanation, please add a ReadMe file for thise concepts. Unfortunately, those explanation cannot be generated automatically.

[Ikochoy]

Why do we have to passed it as input if it is never used? For classes that similar purpose, for example LanguageTextSplitter and RecursiveTextSplitter, although I know this is not provided in current LangChain Document, do you think we should add the scenarios where the first class is preferred and vice versa?

[VictorS67]

Why do we have to passed it as input if it is never used? For classes that similar purpose, for example LanguageTextSplitter and RecursiveTextSplitter, although I know this is not provided in current LangChain Document, do you think we should add the scenarios where the first class is preferred and vice versa?

Fixed