mavenlink / brainstem-js Goto Github PK

BackboneFactory is currently simply pointed at the master branch of a forked repository. We should consider publishing the fork, switching to an already published version, or simply pinning the dependency to a SHA or release tag.

We should only be supporting IE > 10. We should also officially state this in a browserlist file.

It is safe to delete this line.

There are use cases where we are making requests (usually filters) where the parameters are additive and it be nice to have Brainstem add the params to the last fetch options automatically (via a deep merge). We might be able to leverage the existing refresh call and/or make that an option.

On the flip side, we also want the ability to blow away all the parameters (except the ones specified) in case we are performing a reset/clear of the request.

For backwards compatibility, this could just be a refresh to trigger between making incoming options additive vs. replacement.

In the event that A is associated with B. Fetching models A with an include of the associated models from B can be a parallel request instead of serial.

There are some edge cases were promises need to be managed: invoking two fetches from the same collection requires aborting the first one (i.e. only have the last fetch in-flight).

It would be nice to have a collection / model instance cache promises and return them when appropriate. Or, abort previous promises.

I'm not sure which is the right solution at the moment. Will sit on it. Would appreciate thoughts / opinions.

When using expectations in tests, the resulting Backbone Collection does not get the correct state object, which includes totalRecords and totalPages.

After running expectation.respond(), the totalRecords is undefined.

Some of our specs manually set state.totalRecords = someNumber, but this value gets over-ridden once the expectation responds.

I looked for a couple hours between yesterday and today through the expectation source, but could not figure out how to get this to work. Looks like a Collection's state object comes from the Pagination plugin, but it's not clear how it assigns the state data.

This was discovered while working on: https://github.com/mavenlink/mavenlink/pull/1497

There's a detailed description of the issue there, but essentially, that repro is resulting in a situation where a GET that should be adding a record to brainstem's internal cache, is not.

@rogerneel @jhmoore @cantino @jrolfs I've showed this to Andrew and Jamie and confirmed that it's a bug in brainstem. I've decided to hold off on the #1497 fix since it doesn't seem to be getting reported by customers (I reported this myself) and seems minor. Using that fix would mean an http request everytime you select the Linked Posts mode and would mask this bug.

It seems that the addition of feature_name as a request option (for analytics purposes) introduced a failing case when a filter had the key of feature_name.

I think enabling expectations would have caught this since it compares the actual versus expected load options. However, digging into it, I was not able to create a brainstem-js only failing case because the expectations kick in before the custom sync logic. If we were to push the expectations a bit further down the code path, we should be able to capture all the options presented to Backbone.sync and do a nut-and-bolts comparison.

Seems like the computed cache key is missing includes which I feel would produce undesirable results.

e.g.

• Load a collection without any includes
• Reload the collection (same filters and what-have-yous) with some includes (possible as another part of the application)
  • Storage manager would utilize the cached response which is missing associated models

Hi. My name is Verena Ebert, and I am a PhD student at the University of Stuttgart in Germany.
A few months ago, I have examined 90 GitHub projects to see what communication channels they use and how they write about them in the written documents, for example README or wiki. If you are interested in the previous results, you can find them here:
https://arxiv.org/abs/2205.01440
Your project was one of these 90 projects and, therefore, I am interested in further details about your communication setup.

To gather more data about your communication setup, I kindly ask one of the maintainers to do an interview with me. The interview will be about 30-35 minutes long and via Skype, WebEx or any other provider you prefer. The interviews should be done in November 2022, if possible.

In this interview, I would like to ask some questions about the reasons behind the channels, to understand the thoughts of the maintainers in addition to the written information.

The long goal of my PhD is to understand how communication works in GitHub projects and how a good set of communication channels and information for other maintainers and developers looks like. One possible outcome is a COMMUNICATION.md with instructions and tips about which channels could be useful and how these channels should be introduced to other projects participants. Of course, if you are interested, I will keep you up to date about any further results in my research.

If you are interested in doing an interview, please respond here or contact me via email ([email protected]). We will then make an appointment for the interview at a time and date that suits you.

If you agree, I would like to record the interview and transcribe the spoken texts into anonymized written texts. In this case, I will send you the transcript for corrections afterwards. Only if you agree, the transcripts or parts of it would be part of a publication.

Relevant cache keys that match a particular braintem_key should be invalidated when a model is

• Created
• Updated
• Destroyed

I'm having to install an old ruby and I was wondering whether it mattered bumping this requirement.

Seems like an expectation only returns a promise. It would be nice to automatically inject an abort method (just like an XHR).

It seems like the handling of the filter option in sync is incorrect. Here's a failing test

    it "should include 'filters' from options", ->
      model = buildTimeEntry()
      model.save({}, filters: { day: 'today' })
      expect(ajaxSpy.calls.mostRecent().args[0].data).toMatch(/"day":"today"/)

The output:

1. should include 'filters' from options
   Sync updating models
   Expected '{"time_entry":{"project_id":"1"},"include":"","filters":"[object Object]","optional_fields":""}' to match /"day":"today"/.

PR incoming

Since the storage manager is a singleton (which works really well in production), there tends to be pollution in testing environment.

It would be nice to have a easy way to either clear out the singleton or replace it with a new storage manager.

Many existing specs can be made more readable and less repetitive using Jasmine 2.0's beforeAll feature.

Note: this is dependent on #70

Seems like calling fetch on a model multiple times does not cache the response.

Running the tests in Chrome is not that helpful when the browser locks up when trying to utilize the console.

Perhaps test:watch could be useful if skipped tests are silenced.