Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Aaron Eischeid
@aeischeid
I haven't had a much time to devote to Spine lately. Pulled off on other things. So far I haven't really thought about separating out the core model and controller components. I have considered breaking the modules like route and manager etc. out into separate repos. There would be some advantages to that, but also some potential headaches as well. Open to feedback on that
Richard Flosi
@richard-flosi
I was doing a little reading on git submodules last night which doesn't seem to be the way to go, but it sounds like there are a lot of alternative options of which something will probably make sense. I'll be working on something similar at work, so I'll let you know what I find.
Richard Flosi
@richard-flosi
Hi everyone, are people using bind/unbind or listenTo/stopListening when working with events these days? We just started using listenTo/stopListening, but I noticed it doesn't work as documented as far as maintaining the correct context for this and I still have to use this.proxy (we write our app in javascript).
Aaron Eischeid
@aeischeid
I use bind quite a bit, but not listenTo very much. Can you reproduce your issue with a broken test?
also the binding stuff is probably getting a bit of an overhaul soon. spine/spine#558
not sure that would affect your issue, but just a heads up
Michael Matyi
@supernintendo
I noticed there are no namespaced events in Spine (compare with jQuery which allows .bind('foo.bar') and .unbind('foo.bar') without affecting other 'foo' bindings). Would there be any interest in adding this / accepting a PR for this?
I'd be willing to write some CoffeeScript for this feature.
Aaron Eischeid
@aeischeid
Seems like a nice addition to the binding features. I don't know that it would be very widely used, so I would weigh it partially based on the complexity it adds, but yes, I always welcome solid pull requests!
Richard Flosi
@richard-flosi
should i be able to install spine 1.4.0 at this point? I'm getting an npm error currently. Error: version not found: spine@1.4.0
Aaron Eischeid
@aeischeid
I didn't publish to npm yet because I wanted to test it on some real world applications. you can reference the master git branch directly
if your using npm something like this should work
"dependencies": {
    "spine": "spine/spine",
    "jade": "1.8.1",
    "stylus": "0.49.3"},
Richard Flosi
@richard-flosi
@findByAttribute(name, value) and @findAllByAttribute(name, value) seems a bit limiting. I currently have a case where I want to be able to findBy-Multiple-Attributes, which I can do with select, but it seems like it would be easy to add support to these two methods to take an object and then have it return records that match all the key/value pairs in the object while keeping the current function signature available as well. Thoughts?
Richard Flosi
@richard-flosi
I find myself wanting there to be an instance version of fetch for model instances that will make an ajax call for the current record instead of having to get the model and call fetch with the instance id. Anyone else come across this?
veggie
@kkxlkkxllb
Hi, does anyone use firebase with spine.js?
Adam Biggs
@adambiggs
@aeischeid @richard-flosi hi guys! I haven't been able to spend much time on Spine for quite a while... But I've had some stuff on the back burner that I hope to submit PRs for soon(ish).
anyway, just reading through this thread and noticed the discussion about breaking up the Spine core into smaller modules. I love the idea, but IMO we should keep it all in the same repo so communication & maintainability doesn't suffer.
lodash-amd does a great job of having lots of small modules in the same repo: https://github.com/lodash/lodash-amd
Richard Flosi
@richard-flosi
There used to be a file called lib/runtime.js that needed to be included in the js, but that file appears to have been removed from the repository. I'm assuming that is no longer needed, correct? What version phased that out?
Aaron Eischeid
@aeischeid
that is required for jade templates. it wasn't part of spine itself but came bundled in with apps generated by spine.app
Richard Flosi
@richard-flosi
ah, okay, I was wondering were I got that. and what it was for. :) Thanks. I don't seem to need it since I'm not using Jade.
Michel Käser
@michelkaeser
Hi there. Given the changes from spine/spine#591 – if the server backend does a cascading delete (i.e. it also removes all records from other tables that have a foreign key to the removed entry) is there a way to delete the record from Spine without trying to make an Ajax request (because in that case it will fail because the record doesn't exist anymore and re-add it)?

and a problem I do not know how to solve. Let's say I have a model 'Binary' and 'Categories' with an m:n relation and a table that lists all binaries (including one column for the categories it belongs to). Now I'd like to wait for Binaries.fetch() AND Categories.fetch() to have completed before rendering that table. With promises I could do something like:

p1 = Binaries.fetch()
p2 = Categories.fetch()
$.when(p1, p2), -> render

but I don't see how to to that in Spine...espacially in combination with the element pattern

Michel Käser
@michelkaeser

last but not least back to the first point: is cascading destroy something that's on the roadmap (relations module) or if not, how would you implement that?

something like:

constructor: ->
super
@user = User.find(@user_id)
@user.bind 'destroy', @destroy

Adam Biggs
@adambiggs

@michelkaeser

is there a way to delete the record from Spine without trying to make an Ajax request (because in that case it will fail because the record doesn't exist anymore and re-add it)?

You can pass ajax: false into the method options to disable ajax for an action, e.g. record.destroy(ajax: false). Is that what you mean?

re: your 2nd question, you can use Binaries.ajax().fetch() which returns the jqXHR object that should work with $.when().
Adam Biggs
@adambiggs
but we really want to refactor Spine's model methods with Promise support... it's just a matter of finding time to do the work!
And re: your last question, I would extend the destroy() method rather than using events. If you're using model relations it might look something like:
destroy: ->
  @user().destroy()
  super
Richard Flosi
@richard-flosi
FYI @aeischeid @adambiggs I just tried going to spinejs.com and the site is down.
Aaron Eischeid
@aeischeid
I could wrestle with the rails stuff and heroku configs to get spinejs.com back... or we could migrate content into Jekell and host with github... http://spine.github.io/
I could point spinejs.com domain to the github hosted page pretty easily. what is your guys opinion?
Gio
@supermacro
Apologies in advance if this is a total noob question but it seems like you guys are about to do a large revamp of the codebase (based on talk of breaking into submodules), would learning the current version (via the current docs and tutorials) be redundant ? Should I wait until a new version comes out?
Aaron Eischeid
@aeischeid
We have a large-ish rework in mind, but really haven't gone beyond the idea stage yet. learning the current version would not be a waste anyway. The modifications to spine's model retrieval stuff will be a shift in some significant ways, but since it amounts to using promises instead of events, this is significant and not. This is something you would need to understand working in the JS world anyway, and adopting that understanding to spines model stuff shouldn't be to hard when that all lands. That said, the docs and tutorials are getting a bit dated, they are still a good place to start, but let us know if you find places where things aren't clear.
Aaron Eischeid
@aeischeid
@adambiggs what do you think about a 1.6.2 release to bring in the changes/fixes you brought in lately? my initial impression is that this would be a small fix thing and not merit a bigger bump in version.
Michael Matyi
@supernintendo
This message was deleted
This message was deleted
Michael Matyi
@supernintendo
Will the next version be built in CoffeeScript or ES6?
peter lee
@ins429
This message was deleted
Adam Biggs
@adambiggs

@supernintendo sorry for the late reply.

There aren’t currently any plans to move away from CoffeeScript. That being said, I’m personally a little sad about the direction CoffeeScript seems to be headed… If it continues to go stale, I’d be in favour of an ES6 rewrite.

My team at Lightmaker is pretty heavily invested in Spine, so if CoffeeScript dies, it would probably be easier for us to refactor our codebase (and Spine) in ES6 than switch to different library. An ES6 refactor could be mostly automated, but switching libraries likey couldn’t.

TL;DR - Short term: CoffeeScript. Long term: (IMO) If CS dies (or there’s enough demand), ES6.

Aaron Eischeid
@aeischeid
FWIW I am very much on board with that thinking @adambiggs.
Adam Biggs
@adambiggs
@aeischeid just opened a PR that’s a pretty significant upgrade of our test runner :sparkles:
Aaron Eischeid
@aeischeid
@adambiggs noticed couple other bug fix things you had in think a 1.6.3 release is in order?
I should get better about punctuation...
noticed couple other bug fix things you had in. Think a 1.6.3 release is in order?
Robert
@Doogiemuc
About Spine and CoffeeScript. I am a programmer since over 30 years. One little Advice: That story already happened before. A looong time ago there was something called Perl. And it was great. Great developer experience. Great syntax. Awesome libraries. But then JAVA came. And then even JAVA EE. And today a HelloWorld has >15MB. :-)
my advice: as sad ad it sounds, you have zo switch to ES6 if you want Spine to survive. But keep the spirit that this great project has. KEEP IT SMALL & SIMPLE
Don‘t be ad hard to learn as
AngularJS
You will have to look at VueJS. It started as small as Spine but in the last 2 years became a hughe success.
Robert
@Doogiemuc
Spine DOES have its own specual ressons to exist. Eg its Model Domain Model (kind of a very leightweight ORM). And this makes it unique. Keep that