Problem
I call setState to add a new recipe to my recipe list
The recipe is a new panel in a Foundation accordion
The accordion title pops up immediately
There is no functionality until page refresh
I have tried everything i can think of including Foundation's reInit, their manual toggle, up, and down methods for accordions, and re constructing the whole accordion
nothing works
This is the solution I came up with.
i was able to call $("#element").foundation("toggle",$target,true) from the console and programmatically open and shut the accordion tab.
element is the accordion wrapper and target the specific tab, true is a param to indicate reflow needed
implementing that function into my app was more trouble than it was worth, for a number of reasons.
i ended up just calling location.reload() and which essentially is like pressing the refresh button. with a modal animation running at the same time it is barely noticeable
so when all else fails manual over-ride could be a viable solution depending on what your individual page is
There is a real answer
in my research i came across quite a few similar github issues that had to do with Foundation plus some sort of dynamic rendering and/or third party framework/library. every situation is a bit different so there isn't one answer
if someone has specific knowledge of what why Foundation or React(possibly), wouldn't let me reInit,reflow,$(document).foundation or do any of the various supposed solutions: I would love to know.
perhaps I could have done something different but if you look at my code I keep state to one component, I init my js plugins in componentDidMount - as far as i know this is what i am supposed to do. thanks
Related
I am trying to integrate InteractJS and ReactJS and I am seeing a strange but predictable problem on moving items from one dropzone to another and a mismatch between the UI and the underlying state object array. I realise this is most likely a bug in my code due my limited knowledge or React updates and/or InteractJS events - or both - but after three days staring at it I am very grateful for any insight into what may be causing this problem.
I have created a minimal codesandbox to demonstrate the problem.
I can drag all of the items into a dropzone and between dropzones in reverse order and both state and rendered output correctly updates.
However if I drag an intermediate item (i.e. not the last one) from a dropzone into another, React incorrectly re-renders the object immediately succeeding the dragged item in the wrong dropzone.
My question is: Why does the React render not match the state object for intermediate items but works correctly dragging items in reverse order?
Thanks
While researching how to handle multitouch gestures (drag and drop, zoom rotating, etc. of elements) in React.js I first found interactjs. It didn't worked well and after some more research I found enter link description here. Good documentation and it works very well with animation libraries.
I would strongly recommend not to use interactjs in a React project.
So, it's hard to build long, infinitely scrollable lists with lots of bindings without compromising performance. There are many ways to overcome that, but I noticed one particular problem I have no idea how to solve.
Basically if you have long ng-repeat with lots of items and whenever you append or change the data - UI blocks horrendously. The more data you update - longer the freeze.
you can see it on that jsBin - everytime you click the button UI freezes
Is there a way around that?
upd: I thought maybe I should try React and studied this popular post about using React with Angular - seems React won't solve this problem, see this plunker
I am very new to all things Angular and have been experimenting with some stuff.
Been playing with UI-Router and with Angular Animations.
So far everything is going to plan, except one thing.
During the transition between pages (my top-most states) the footer area collapses up under the main content and against the navigation.
(I'm also fairly new to css transitions, so my knowledge is limited, but growing)
Is there anything that can be done to prevent this from happening? Maybe have it snag on to the height of whichever state is the tallest? (IE, the one leaving, or the one entering)
(I've tried searching everywhere, but whatever I search for I come up dry. Maybe I'm searching the wrong keywords.)
I have included a plnkr link
Thanks in advanced.
I dont hope to get any answer but i will try to be clear.
I tried Caliburn Micro . At first it seemed fine and all i need. Some features yes but other not.
All i wanted is a single window with some views as usercontrols and multiple dialogs at each view. Using a conductor.OneActive i could achieve the first with little pain. However switching between views even looking the example was to cast Parent to Conductor and call a method there.
Even example of caliburn micro did casting like this. Calling .close(false) at screen was same as close(true) resulting in killing the view and recreating causing lag in lowest end atom pc.
So only solution was to cast to parent.
Dialogs
I tried tons of dialogs examples but non worked and made my life hard.
Messagebox etc were DEAD easy but in case you wanted multiple dialogs you were out of luck.
If you put code at close callback to open another dialog you got bonus stackoverflow exception as it gets confused.(Endless loop).
I could figure a good dialog that could cache the view and at the same time to display efficiently multiple dialogs.
Event Aggregrator
Also i cant figure out how on earth event aggregrator is suitable for switching views. In case you have multiple conductors it could be a hell to manage.
To show a dialog - as in Modal Dialog that blocks the view that showed it - you should be using IWindowManager.ShowDialog.
You should take a look at prism library http://compositewpf.codeplex.com/
see navigation chapter: http://msdn.microsoft.com/en-us/library/gg430861%28v=pandp.40%29.aspx
But I don't know how EventAggregator could help you to switch views… you could subscribe to received an event on a closingView but… …
You might want to take a look at Catel. It has a UIVisualizerService which allows you to show windows based on their view model.
It also has a ViewManager (IViewManager) which allows you to manage all views inside your whole application. Besides that, it also provides a ViewModelManager (IViewModelManager) which does the same for your view models. Best of all: you can find all views that are connected to a specific view model in your application to interact with that.
I have a certain UI element, which when clicked should navigate to another URL.
I tried handling the mouse down event and execute something like this:
System.Windows.Browser.HtmlPage.Window.Navigate(new Uri("http://google.com"), "_blank");
However, this gets blocked by the browser (I tried both Chrome and Firefox) unless I disable the popup blocker.
I did some research and it seems that the browser blocks navigations that don't occur as a result of user interaction and as far as the browser is concerned this navigation is initiated by a plugin (Silverlight), not a user.
OK, makes sense. But then I tried using a HyperlinkButton instead and it was NOT blocked.
I wonder why these two approaches get different treatment from the browser. Any idea?
I actually worked around the problem by wrapping the navigation triggering UI with a HyperLinkButton, but I'm still very curious...
I'm going to pull a fancy corporate quote and say "It is a feature, not a bug."
The Silverlight team is obviously worried about Security. They don't want crazy haxorz like you and I to do crazy things with our apps--you know, like popping up a bunch of browser windows all routing people to Zombo.com. Just imagine the choir! Zombo!
Summarized from their documentation: They want us to only use the HyperlinkButton to go outside of their application. In fact, they went the extra step, and depending on our settings, they will even throw a SecurityException for us if we navigate to an outside page--Even from a HyperlinkButton. How nice.
The real question: Why the Hyperlink Button and not something else?
Only one "thing" can navigate. this take saves time for Microsoft while testing Silverlight. This one thing can navigate to both internal XAML pages and external web pages--Might as well be consistent and have only one way to do navigation.
It is a UIElement. It's code behind likes to run in the primary visual thread. It can promise the browser that a Visual Element wants to go somewhere. Microsoft can also put its limiting logic in a control that requires a mouse-click/keyboard-input event tree.
All in all, it makes sense to start simple by making a control do the work.
Fun stuff! Hope this helps you.