Refactor Subway

[thedjpetersen]

So I have begin work in completely refactoring subway. Here is a bit of the roadmap(checked boxes are completed tasks:

• Rewrite the frontend so the views use the Facebook React library - this makes the frontend code cleaner(including the event handling system)
• Handle raw commands on the frontend - this lowers the chances of missing IRC commands on the frontend, I want to switch just on raw commands and numeric codes
  • List of commands are here: https://www.alien.net.au/irc/irc2numerics.html
• Handle user commands
• Handle commands on the backend
• Using Open Sans as the default font
• All clientside dependencies are managed with Bower
• Implemented a Grunt build system to handle script compilation
• Layout is all flexbox
• Rewrite the backend with a focus on simplicity(this is a bit of a wash how well this has been accomplished)
• Write a plugin handling system to handle messages on the client - this would make it easy for others to write plugins and then just specify them. Instead of creating issues here.
• Solid mobile support

I would love to hear ideas about the architecture or how this transition should happen. At the moment I believe creating a separate branch and working off of it.

[BYK]

I kind of think React's way of mixing JS and HTML is not really good. Otherwise all looks great and I'd like to give this a hand if possible.

I've actually ported the IRC handling library on the backend to front-end, if you think that would be useful. I'm willing to help with any other tasks too.

[tlaundal]

This sounds good. It's nice to see some activity on the project.

[thedjpetersen]

@BYK is your only issue with react a stylistic thing?

[thedjpetersen]

Ok I have put the work on the refactor branch - very little works, just a heads up

[BYK]

@thedjpetersen, it is more of a philosophical thing. I believe in separation of concerns but I'm also open to new ideas. Since you've already done the hard work, I say why not? :)

[46bit]

This sounds great. I've been working on a refactor to enable multiple IRC networks etc (https://github.com/46bit/subway) but trying to keep it working the same.

[thedjpetersen]

@46bit I am taking that approach from the beginning with the rewrite

[hermansc]

How will this affect future commits and pull-requests to the master branch?

[thedjpetersen]

@hermansc as soon as the newer version reaches feature parity - I would like it to replace the master branch. If the refactor stagnates - nothing will change.

[46bit]

@thedjpetersen: It would be great if you could hang out in #subway on Freenode?

[thedjpetersen]

@46bit sure I'll hop on for a bit

[thedjpetersen]

Quick update:

The rewrite is coming swimmingly so far. Handling and emitting raw IRC commands has been much easier than working with the node-irc wrapper commands. As you can see from the checkbox list above I am working slowly trying to get parity with weechat commands. I need to ensure that I am handling every received event on the frontend as well. If anyone wants to help with this be sure to ping me and I would love to give more info on this. After the client can is fully functional, I'll work on adding persistence and then polishing up the UI.

[thedjpetersen]

Took some time off of writing support of commands to polish up the settings. Next up is porting the legacy persistence/auth setup. I would love to hear feedback about the settings work I did as well.

[tlaundal]

I would like to thank you for doing this rewrite, @thedjpetersen. I really appreciate it.

I will look into doing some of the commands later this weekend.

[thedjpetersen]

So the work for backend persistence is well underway. I have sketched out something basic right now and committed it. I will have to revisit it. At the moment everytime there is a state change in the client I am just persisting it with a sync call on the client. I will need to implement something that keeps track of a logged in client through a server method.

[thedjpetersen]

After discussing with @hermansc in the IRC channel - its clear the most optimal way to keep track of the state of client on the server is to modify the client code so it can be used by the server. This includes the backbone models and the irc handling code.

[thedjpetersen]

Fixed some minor bugs with the persistence going to add logging of messages next - also need to move that massive checklist of commands above somewhere else

[thedjpetersen]

Basic logging implemented - need to make it so when history is loaded it doesn't greedily continue to load history. This should be accomplished by maintaining the scrollbar position.

If I could get some feedback on this work from anyone I would really appreciate it as well.

[thedjpetersen]

Getting really close to a RC - could really use some people to help me test the client out and identify bugs.

[chiguireitor]

Going to download it right now, i'm using this as the support channel for my business :)

[badosu]

Really really good job @thedjpetersen!

Know if the plugin api is already defined? Would care to explain how it works, if so?

I am thinking in cleaning: https://github.com/badosu/subway/blob/master/assets/js/views/message.js#L30-32

[thedjpetersen]

Badosu - I haven't documented it yet but it works more or less like this:

Info about creating a plugin:

• Plugins are Github gists(the easiest way to create them is to fork an existing one)
• To add a plugin to subway you need to add it here(https://github.com/thedjpetersen/subway-plugins/blob/master/plugins.json)

---

Plugin syntax

• Plugins are defined to the app.plugins namespace
• The plugin method accepts the message - and returns the parsed message(as an html object) and a listener(which can be attached to the element)