I have a view with a bootstrap accordion. Navigating to the view, away from the view, and back to the view disables the accordion functionality.
I imagine the problem is that once the HTML is rendered, it isn't fully disposed of on navigate away?
Any solutions?
My fault.
I had made two naming mistakes. First, instead of changing the IDs of the two accordions, I changed the classes. Whoops. Second, two of the tabs IDs overlapped. This allowed the first one to work, the second one to override it, and the first one to break in the process.
The view composition handles this case well.
Related
In the application we are developing, we have a CollectionView whose every ItemView contains a link to the item-details page. Also, every ItemView contains a checkbox, because items can be selected in the CollectionView to perform bulk actions on them.
When switching to the ItemDetails view, we want to keep the state of the CollectionView, ideally without having to redraw it (a bit like GMail when switching from inbox to mail and back). Our solution is to render the two views in two different regions and to hide one when switching from one to the other.
My perplexity about this solution is that
Marionette doesn't seem to be meant for this kind of use.
It is not very memory-friendly, since all the DOM elements are never deleted.
Is there any better solution to achieve this goal?
Storing the state somewhere, close the CollectionView and redraw it later is another possible solution, but would it imply a heavy computation overhead? (we are quite scared about redrawing views).
Marionette allows for showing a view in a region without closing the view that was already rendered. You simply pass in {preventClose: true} to the show() method of the region. You would still need to maintain a reference to the collection view though so you can later re-show it or close it yourself.
https://github.com/marionettejs/backbone.marionette/blob/master/docs/marionette.region.md#showing-a-view
Unless your collection is very large, there's not a problem with just rerendering the collectionView when switching back from a itemDetail view. You do need to store the state of the checkboxes indeed.
However, I don't see what's really wrong with your other approach. It's probably even faster and there's nothing wrong with just hiding one region and showing another. If that works for you, go ahead.
Regarding the memory issue, as long as you're looking at the collection or itemDetail there isn't much to gain by closing either one of the views (especially if your itemDetail views are not very large). Once you move away from that section (thus not looking at the collection or itemDetail view anymore) you could just close the layout that contains these two regions. That'll free up any memory used by these regions.
In my app, I have a menu that is consistent across pages/view, and a sub menu that shows different links (to more nested child pages) for each main page/view. I am unsure how to approach changing the sub menu. For now, I have both the menu and sub menu in the body, as well as an ng-view element.
First I thought I'll make a controller for the sub menu and loop over an array of sub pages to display, updating the array as the main page/view changes. This seems cumbersome and unintuitive, though, as I'd have to keep a list of sub pages for each page in this separate controller, when really, they are part of the main page's/view's logic, no?
Then again, I've read about the angular ui router and its implementation for nested views - should I rather approach the sub menu as a nested view?
I know SO cries to see my actual code, but I am more struggling with how to approach this problem, not with how to implement it. And it seems to me that something like a sub menu changing per page/view must be a common enough problem, that there is good recommendations for how to solve it.
I'm not sure I understand your scenario correctly - I'll assume a situation where there is a top-level navbar where each navbar item has a set of sub-items (a sub navbar). Also, each top-level navbar item represents a distinct functional area and consequently each has their own model. Hopefully that is close to your situation.
Given that, I'd think that you could have a separate controller for each top-level navbar item (i.e., each functional area). Each of these controllers would be a child of your top-level controller, and each might have their own child controllers.
Put another way, it might help you to think of your app in terms of distinct functional areas, and using the MVC pattern for each area. This might make it easier to reason about your app, and easier to write tests, as opposed to using a single controller to represent everything.
I hope that helps..
It's a good question.
I think that for major flow use the route and for inner panels use widgets. create directives that compiles templates.
I built a dynamic widget you can read about it in here
You could use a ngShow directive for each sub-menu, with code to decide whether it should show or not. You would probably need a different function for each sub-menu which may or may not be shown.needs to be hidden.
I'm thinking about the optimal way to structure my Backbone application. The problem is that I have various complex states, each made by some views showing while all the others are hidden.
What is the canonical way to handle this in Backbone? Two things that I've thought are either controlling the state by the router (calling views hide / show methods) or making the views listen for route event.
The problem with the first method is that the router must be aware of all the views existing in the application.
The problem with this second solution is that I have to make all the views listen to all the events and hide for any of them but a couple that make them show.
Thanks for pointing me to a lean solution.
I use a FSM machine to change the state of the application. Each states shows and hides the appropriate view. My views use transition to animate in and out, so changing the state is more complex, then simple show/hide - it animates in and out from one state into another. I have forked https://github.com/fschaefer/Stately.js to fit my needs.
I can share my personal experience with such a problem. I don't know if it's the best solution, but it worked for me.
My problem was even worse because I had several routers and each of them should hide/show views that belong to it. The solution I chose was similar to the first option you consider.
In my router there is an array which holds all existing views. When the state changes and route callback executes all other views are hidden with this simple code view[i].hide() and the proper one is shown. You can make View model and Views collection if you would like to have more control.
I think it's a better solution, because when you add a new route, you don't have to add route events to all views. Moreover, your views stay decoupled from the router, they may even don't know it exists.
I'm starting to learn Backbone.js and can't figure out one thing: In a typical rails app, I have a layout view and a nested view. My layout usually contains navigation links that are processed by rails routing.
How do I do the same with Backbone? I'm using Rails 3.2 and eco templates.
Should I create nested templates in eco?
Should my navigation links be plain html links with a href or should the navigation be event driven?
For example I have a list of categories on the left, and a category items on the right. I want my categories to be shown on every view and the corresponding category items (with a URL in browser corresponding to selected category) too.
Please point me to right direction, because most tutorials on the Web are 'todo' style applications with no navigation at all.
Thank you.
UPDATE
Turns out, my question wasn't clear, so let me narrow it down.
How can the concept of RoR layouts be applied to backbone.js applications?
And I'm curious about two possible ways of navigation:
create
%a{:class => "customers", :href => "#customers"} Customers
handle ".customers click" event in my view
Which way is better?
And I'm curious about two possible ways of navigation:
create %a{:class => "customers", :href => "#customers"} Customers
handle ".customers click" event in my view
Which way is better?
neither is better until you know the specific context in which you are working. they are simply options for achieving your goal and desired functionality.
there are times when both should be used, as well. for example, if you are supporting search engine optimizations and accessibility.
Here are some better questions to ask:
Which of these will be the simplest thing that can get the job done? will it be more code to write the route handler, or the click handler?
Will the route handler tightly couple the functionality to a router, when I don't need that?
Do I really need a route for this link, so that people can bookmark it and come back to it directly?
Will a click handler cause my code to jump through several hoops of calling other objects that aren't directly related, or can I use a simple event to cause the other objects to run?
There isn't a single correct answer to any of these questions. I recommend trying many different ideas when you can. Keep in mind that you will likely change your answer as you develop new features. The answer that you want, today, won't be what you need tomorrow. But that shouldn't stop you from picking an answer now and moving on. Pick one, put it in place, and when you need to change it, change it.
I'm working on creating a Javascript Tab library. Actually, it's already been developed and is working great. But it's due for a rewrite to fix some underlying annoyances and quirks we've found while using it. Anyway, here's the current model.
The current model has a TabSet object, which houses the main functions for the tab library: addTab, removeTab, showTab, hideTab, and related history functions. Then there is a Tab object that contains the data/methods related to the tab: showThrobber, hideThrobber, reload, and creating the actual DOM elements for the tab. Now, you can see this is a bit disjointed. TabSet handles showing a tab and hiding a tab and Tab handles reloading the tab.
Here's the question: What is the best way to organize the methods for this tab library. The problem we are running in to is that the current model, while disjointed, makes sense. TabSet is indeed showing a tab, hiding a tab and removing a tab. But the Tab itself is indeed being shown, hidden and removed. Really, all the function make sense to be in either class: TabSet or Tab.
Let's use an analogy. When someone needs to talk, everyone needs to stop talking. There are two ways for this to happen. 1) The leader (TabSet) tells everyone to stop talking and then tells the speaker to start talking. 2) The speaker tells everyone to shutup and starts talking. It makes sense to have the controller tell other Tabs to hide and tell the new Tab to show. But it also makes sense to have the Tab tell all the other Tabs to hide and then show itself.
What are your thoughts?
Personally, I'd design it so that a Tab only knows about itself and the TabSet that is managing it. It wouldn't carry a reference to the other tabs.
I'd put show() method on Tab; internally it would ask the TabSet to hide all other tabs and show itself.
I'm assuming exactly one tab must be shown at all times, so there's no point in having a public method to hide an individual tab.
The idea behind that design is that you have less error checking to worry about. If your TabSet object had a showTab(tab) method, you'd have to check to make sure that the tab being passed in was actually one of the tabs in the set.
Usually when I design an API my first priority is to make it hard or impossible to pass in invalid inputs.