Topics!

[Brandon Mason]

Anyone have topics they'd like to discuss this Wednesday?

Michael had the idea of starting some kind of long term project that we could all collaborate on.  If people are interested, we could have a discussion around what we want to do, and figure out our first steps.  Probably something like:

Idea Discussion -> Feature Planning -> Technology Decisions -> Divide and Conquer -> Deploy -> Get Feedback

I imagine it will take multiple meetings and some work in between to get us through the whole process.  My preference would be to have the people who are looking for code experience do the actual coding, and those of us with more experience will help you get over any stumbling blocks.

Anyone else have topics?

--

Brandon Mason

Torchlight Software

623.882.4246

[Jon Nyman]

I think you guys might have gone over this before but I have questions about React.js. I'm trying to convert a webapp I made with Mithril.js to React but they're two different worlds! I was wondering how to go about routing on the front end and what to use for Ajax calls, maybe a quick demo project would be nice.

[Jon Nyman]

Going over exactly what Sweet.js is would be interesting too.

[Brandon Mason]

I use react-router and I'm liking it a lot.

There's several competing implementations of 'flux', including Facebook's examples (somewhat meager), Fluxxor (community driven), and Yahoo's implementation.  In any of these ecosystems you'll find more out-of-the-box solutions... but if you're shooting for a Flux architecture you are almost certainly going to have to make a lot of technology decisions and wire stuff up yourself.  It's still an emerging, immature ecosystem.

A simpler alternative might be to simply use Amersand or Backbone, with React views.

As far as Ajax calls go, they belong in the Action Creators/Actions area if you follow the Flux diagram.  What you use to make the actual calls is up to you.  You could use the native browser API, or jQuery, or some microlibrary.

On Wed, Jan 7, 2015 at 1:44 PM, Jon Nyman <nyma...@gmail.com> wrote:

I think you guys might have gone over this before but I have questions about React.js. I'm trying to convert a webapp I made with Mithril.js to React but they're two different worlds! I was wondering how to go about routing on the front end and what to use for Ajax calls, maybe a quick demo project would be nice.

--
You received this message because you are subscribed to the Google Groups "Phoenix Javascript" group.
To unsubscribe from this group and stop receiving emails from it, send an email to phoenixjavascr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brandon Mason]

Maybe you could do a sweet.js demo and tell us about it.  ;-)

[Jon Nyman]

Thanks, I'll check those out. Maybe I'll get a sweet.js demo together for February :)

[Thomas Milas]

Brandon, 

I like that idea of a long term project. It seems like one of the challenges of the group is getting hands on the keyboard. I found where I learn the best in these groups is the hackathon! Of coarse this happens at events with larger time commitments like at HolidayJS.

There seems to be a lot of questions about getting started where the student hasn't attempted to start a test project. It would be nice to have attendee's prepare for the workshop prior to the event to get them involved in the technology prior to jumping in the fire. Lukas did this for HolidayJS on his blog. Unfortunately this cannot be relied on. Many of us have very busy lives outside of meetups...lol I'm guilty of not being prepared for HolidayJS and was going over preparation material during breaks.

We could breakup into groups with our project in mind. For those that have a new project in mind and want to see setup then we can start a new micro project. We should ban todo apps...jk. There will also be a group for a long term project that will evolve each week and learn off each other. Interdependence! Extreme programming at it's best.

For this to work a Project is always required. Discussions will happen when problems occur, program design sessions and solutions are needed. 

For long term projects the topic will be what to work on or what we are going to complete. We could even implement Rob Rich's Micro Agile methodologies. Could even use Kanban with trello. Simple and effective for small projects.

I really want to get into react. My next project is going to be in React at least for the V. The Router looks interesting. May use in conjunction with Angular. 

It would be neat to use the format to scale a React app with a simple idea. Not just a todo, something that could benefit our community.

[Brandon Mason]

Good ideas, Thomas, all of them.  We are definitely heading in the direction of doing more projects.  I have some ideas for the next meetup that I would like to try.

I think we should use the time at the library to form project groups and get started on something that could be presented at the next month's meetup.  Project groups would be responsible for keeping in touch with each other and making sure they have something to present.

I envision providing two major things to the group members:

1. Tools and processes that will enable them to create.
2. A venue in which to present the results.

I will need help from the more experienced members in creating those tools and processes.  I'm also working on an online gallery where we can showcase our work (and get feedback/statistics on how people are using it).  This will be open source, and once a foundation is created we can collaborate and accept pull requests for features and fixes.

I'll be sending out more info and requests for collaboration in the next two weeks.  Stay tuned!

Also, hit me up if you have questions about React.  That's my bread and butter.  Here's a presentation I went through on Wednesday.  Not sure if you were in the group or not:

http://pres.tlsft.com/react/

Also a guide for understanding the demo code:

https://www.codementor.io/tips/8243903197/react-meteor-demo

Best wishes,

Brandon

--

You received this message because you are subscribed to the Google Groups "Phoenix Javascript" group.
To unsubscribe from this group and stop receiving emails from it, send an email to phoenixjavascr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Thomas Milas]

Very nice, looking  forward to the next one. Let me know if you'd like me to help with a few things. It would be nice to get things rolling.

React and Flux look very interesting. I'm studying the stack to trying to understand it. From what I understand there are a couple forks in the community. Fluxxor and a few others. There seems to be a bunch of them. For learning the stack what route do you recommend me taking? The official facebook flux? 

On Tuesday, January 6, 2015 at 6:12:29 PM UTC-7, Brandon Mason wrote:

[Brandon Mason]

Yeah...  The fact that React released without any underlying models or server communication caused a lot of confusion in the ecosystem.  It's also good in a way though, because the ecosystem is much more modular and the pieces are able to evolve independently.  So you won't get a debacle like the recent Angular 1.0 -> 2.0 changes.

I would recommend starting out by not using Flux at all.  Take your pick of model technology and inject that into your views.  I'm the only one I've heard say that though.  My reason is this:  Flux introduces a layer of event driven interactions which might be more than you are willing to chew.

If you want to ensure the consistency of a system where people are simultaneously editing resources, or where you're merging multiple live data streams, then Flux is a beautiful solution to that problem.

If your interactions are more simple though... Say you're creating a chat system or an application that lets people manage data which is largely siloed/owned on a per user basis...  You probably aren't going to run into resource conflicts, so a simplified model can be used.

The gist of this is you take the second diagram here and remove the Dispatcher.  Stores become Models.  When you get a UI action, you modify the model.  When you get "updated data" action from the server, modify the model.  If you get a conflict, blow up into a thousand tiny little pieces.  :-)  Or maybe use a model technology that provides facilities for reconciling conflicts?

I'm currently using Loopback for my server and client side models.  I created some React mixins that handle the data bindings.  I might put this stuff together as a library at some point.

Your mileage may vary.  If you have the time to study Flux I'd say go for it.  But don't feel like you have to jump through those hoops in order to use React.

--

You received this message because you are subscribed to the Google Groups "Phoenix Javascript" group.
To unsubscribe from this group and stop receiving emails from it, send an email to phoenixjavascr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.