Project/Codebase overview
Folks are interested in a walk through of the codebase including explanation of environment variables.
Let’s use this thread to organize our thoughts and approach to get something in place to help with the on boarding process for new contributors.
Additionally, one of our focus is to migrate to Vue for our front end view library (from Blaze). In order to achieve this, we need to complete a refactor of our project structure prior to this migration.
Let’s use this thread to also cover this work.
How complete is complete? If we assume that the functionality stays equivalent to the current site, what would we change about the implementation (and why).
Complete means when we have a project structure that allows to migrate our very first blaze template to Vue and is in line with best practices of a typical Vue project.
The main change would be our existing view templates. We would move to more of a component based UI which is where modern front end development is heading today.
The main motivation and goals for doing this are:
Migrate to a more modern UI library or framework where we can leverage better documentation, active community and best practices (component based architecture)
Increase the number of contributors by going with a more supported and active UI library or framework
Specifically chose Vue because of the ease of use, learning curve and smoother transition from Blaze (see template interpolation and mustache syntax)
Decouple the front-end from the backend (in the event we ever wanted to move away from Meteor in the future for example)
All of this will allow us to continue leverage front end dev best practices from a progressive framework like Vue while keeping the entry to barrier for new contributors very low.
@sebbel Can you explain what you’ve done so far in the feature/unfurl branch? That one commit is quite a big diff to try and read through.
Could you please live-stream the walk-through, so people can watch who might miss the hangout? Also a good way to promote CodeBuddies 
I’m interested as to why Vue was selected, rather than something like React @d3vild06?
This is the first I’ve heard of it. I’ve had a brief look through the Codebuddies meta on Slack, and can’t see a conversation about it. Did I miss something?
By no means do I mean to start a React vs Vue is better conversation on here: everyone has their individual preferences.
But… if we look at the Codebuddies community on Slack, there are zero comments in the Vue channel and zero Vue study groups.
Meanwhile, there are a bunch of React Study groups, and an active community of React developers.
I’m also interested in @linda 's thoughts?
I’ve had a brief look through the Codebuddies meta on Slack, and can’t see a conversation about it. Did I miss something?
Searching through #codebuddies-meta isn’t dependable because we lose all the Slack history after 10K messages, heh. A lot of the channel are sadly artificially quiet because of that reason. I know a couple of core contributors are (or have been) working with Vue, although I would wager there is an equal number who have experience with React.
Here’s the original discussion that touches on Vue vs React on the Github issue: https://github.com/codebuddies/codebuddies/issues/211
I personally don’t have a preference on the framework, but then again I am not leading this initiative (@d3vild06 is).
Could you please live-stream the walk-through, so people can watch who might miss the hangout? Also a good way to promote CodeBuddies
Happy to share there are now some new recordings on https://www.youtube.com/channel/UCOBp46r9_g8kKRCc0y-rJVg/videos featuring recordings of code + PR walkthroughs.
Ahh, with 1751 commits since it started, it’s clearly a decision that was made a long time ago.
When I read:
Specifically chose Vue because of the ease of use, learning curve and smoother transition from Blaze (see template interpolation and mustache syntax) - @d3vild06
I thought it was a recent discussion. No worries.
On a separate note:
While you’re doing a walkthrough of the project structure, can you add a map of the file-tree to the readme so that it’s clear where the code should live?
Here’s your current directory structure to get you started:
|-.meteor
|-server
| |-home
| |-comments
| |-twitter
| |-migrations
| |-messages
| |-app_stats
| |-hangouts
| |-discussion_responses
| |-seeder
| |-discussions
| |-resources
| |-admin
| |-learnings
| |-conversations
| |-cron_job
| |-users
| |-availability
| |-activities
| |-slack
| |-seo
| |-study_groups
| |-archived_users
| |-notifications
| |-email
|-imports
| |-ui
| | |-components
| | |-pages
| | | |-users
| |-libs
| | |-server
| | | |-cb_mailer
| | | |-user
| | | |-cron
| |-api
| | |-unsubscribe_links
| | | |-server
| |-startup
| | |-server
| |-data
|-.deploy
|-public
| |-images
|-private
| |-templates
| | |-seo
| | |-email
|-lib
|-i18n
|-client
| |-css
| |-compatibilities
| | |-timepicker
| | |-select2
| |-libs
| |-layouts
| |-templates
| | |-settings
| | |-home
| | |-comments
| | |-inbox
| | |-resources
| | |-other
| | |-admin
| | | |-landing
| | | |-inc
| | | |-notification
| | | | |-inc
| | | |-user
| | | |-dashboard
| | | |-report
| | |-hangout
| | |-status
| | |-profile
| | | |-profile-learnings
| | | |-profile-hangouts-joined
| | | |-profile-edit
| | |-availability
| | |-usr-notification
| | |-members
| | |-nav
| | |-discussion
| | |-study_groups
Which you can get with: find . -type d | sed -e "s/[^-][^\/]*\// |/g" -e "s/|\([^ ]\)/|-\1/"
Thanks, that’s really helpful! IIRC, the file-tree will change when the refactor happens, so will hold off on adding it to docs until then. Right now, we have semi-explanations at https://docs.codebuddies.org/walkthroughs/index.