Refactor status destinations (e.g., Twitter, FB) so that they are more modular
Closed this issue · 1 comments
This turns out to be a prerequisite issue to some of the others that are already here: the possible status destinations and their associated code/data need to be restructured so that they are more modular. They should be separated better so that they can be developed independently of each other. This restructuring should also help with user profile management, particular with regard to the assorted social network accounts that a Quo user might have.
Some broad strokes: the code for each destination should be placed in separate files. Further, the status-posting service should separate shared status-posting logic (i.e., running statuses through the pipeline functions) from service-specific activities (i.e., Twitter API, FB API, etc.).
In addition, the user profile information that relates to the different social network accounts should be well-integrated with this status design.
This is done. The former monolithic status-posting code has been moved to twitter.js. When Facebook posting is implemented, its code should reside in facebook.js, following the pattern in twitter.js. status-service.js has been modified so that it will post to whatever destinations are available in the app.DESTINATIONS object.