Structure for the thread that needs to be passed to the handlebars template

[Mira-Alf]

• Here is a gist that contains the structure of the JSON object that the handlebars template expects: https://gist.github.com/Mira-Alf/29262cec0252cbd72e1f93358fc28c20

Important attributes explained

• threads array attribute containing multiple thread objects
• each thread object contains a common json object and data array containing multiple tweets
• common json object contains attributes: created_at, count and a user json object which in turn has:
  • name, username, description, profile_image_url, verified
• data array object contains multiple tweet json objects. Each tweet object contains the following mandatorily: -id, created_at, tweet
• Each tweet object may also additionally contain the following optional json objects:
  • Tweet with image, video or gif: customMedia json object with photo|video|animated_gif json array.
    • Each of the photo | video | animated_gif objects can contain the following attributes: width, height, preview_img_url, link
  • Tweet with a url and an embedded image of the url: linkWithImage json object which in turn contains the following fields:
  • title, description, expanded_url and an images array with a large image and a smaller image url
  • Tweet with an embedded tweet in it: embeddedTweet json object with the following fields:
  • id, created_at, text, embeddedTweetUser json object with name, username and profile_img_url attributes of the embedded tweet's author, customMedia json object with link, preview_img_url attributes

Questions

• Standardize the structure??
• Displaying date information on the tweets is not being done in the PDF currently. But according to issue #773, @proful wants to display date of tweets for the user timeline tweets. This in turn means we might need a flag in the json structure like isUserTimeline or type_thread: "user timeline, thread, multiple threads" to decide when to display the date or not
• Any other metadata we might need at the handlebars level can be added at this stage?
• For issue #818, @proful wanted replies by a user on a thread to which the original author of the thread has replied, what about the json structure for this scenario?

Will be good to have some clarity before making changes in the code.

Currently we have our code producing pdf for the three different scenarios:

• Single user thread with user information followed by the tweets of the thread
• Multiple user threads with user information followed by the tweets of the thread for each thread
• User timeline tweets of a specific user and some recent tweets

Things to do:

• On a specific thread if we want to include replies by the thread author to other users on the thread. This could be a clarification on the original tweets on the thread and hence it becomes important to capture the question asked by someone else and the reply made by the original author to that question. This is issue #818
• Adding date information to user timeline tweets since @proful requested this on #773
• Sources other than twitter like Hackernews, Github we will need a common format to handle these input sources.

Will need an elaborate discussion on this.

[Proful]

For issue #818, @proful wanted replies by a user on a thread to which the original author of the thread has replied, what about the json structure for this scenario.

For this I think it should be different flow, json and templates. Just a thought.

[johnjacobkenny]

@Mira-Alf Correct me if I'm wrong, but the structure that you have shared has many similarities with the twitter response structure. Do we need to have all of the fields and the structure as twitter gives us?

[Mira-Alf]

@Mira-Alf Correct me if I'm wrong, but the structure that you have shared has many similarities with the twitter response structure. Do we need to have all of the fields and the structure as twitter gives us?

Hey @johnjacobkenny the structure that I have displayed here has all the elements that the pdf template needs for complex tweets rendering. So @PuruVJ has basically picked off the elements that we will need from the twitter API response - sometimes, he has picked objects without destructuring, so it looks more complex than it needs to be.

But now I hope you understand my hesitation in cleaning this up because there are too many elements involved. So it will be good to have a discussion to get a clean structure which we can also replicate for other structures.

[johnjacobkenny]

@Mira-Alf I feel that it would be good if we could come up with a structure that is not tied to twitter API, then we would be able to know better which parts go where.

[Mira-Alf]

@PuruVJ, @johnjacobkenny and I had a call about this issue. And @PuruVJ suggested a structure like this:

{
   "data":[
      {
         "id":"id",
         "date":"date",
         "text":"berirv",
         "type":"original"
      },
      {
         "id":"bev",
         "date":"bbf",
         "text":"bebrkv",
         "type":"question",
         "reply":{
            "id":"jbvbkvjbj",
            "date":"bekjv",
            "text":"bvj",
            "userInfo":{

            }
         }
      }
   ]
}

There is one issue with this structure - it doesnt record what tweet of the thread the reply tweet is a reply to.. I am going to work on this structure with an example tweet and update this issue.

Others please leave comments on what you guys think

[johnjacobkenny]

@Mira-Alf could you please format the content so it is readable

[Mira-Alf]

@Mira-Alf could you please format the content so it is readable

Does it not look formatted? It looks like that to me.

The new structure is in this updated gist: https://gist.github.com/Mira-Alf/29262cec0252cbd72e1f93358fc28c20

Here are the key attributes:

• replies is an array on every tweet object
• every reply is a tweet object which is a tweet made by another user on one tweet of the thread with all regular tweet fields.
• every reply object has a user object which has all the user information of the person who posed the reply.
• every reply object has an answer object which contains all the tweet fields of the answer tweet provided by the author of the thread.

So now every reply is tied to one tweet of the thread and every reply has user information and answer provided by the author of the thread

Let me know if you guys have any questions

[johnjacobkenny]

Sounds good to me! 🥳

[PuruVJ]

We have standardized on a structure (For now 🙄). See https://github.com/twindle-co/twindle/blob/main/twindle-cli/src/twitter/types/types.d.ts#L155

A little snippet here:

export interface CustomTweetData {
  id: string;
  created_at: string;
  tweet: string;
  customMedia?: CustomMedia;

  linkWithImage?: Partial<LinkWithImage>;

  embeddedTweet?: ConversationResponseData;
  embeddedTweetUser?: User;

  replies?: Reply[];
}

export interface CustomTweets {
  common: {
    id: string;
    count: number;
    created_at?: string;
    user?: Partial<User>;
  };
  data: CustomTweetData[];
}