Several months ago I met a flux and I found it's awesome, I love it, I use it.. almost in every new project and when I met a redux I love it even more, but couple of days ago Pete Hunt publish a tweet where he judge the people to use flux for everything. And I think it have a perfect sense, but on the other hand I don't get it.. He publish another tweet where explain cases for flux, also I read an article about use cases for flux. Long story short - "If your app doesn’t have complex data changes and caching, don’t use it. But if it does, I strongly recommend you try Flux." and it's totally make sense for me why I should use flux, but it not clear to me why I shouldn't if I don't have a complex data changes.
In the article Dan point, that when you faced those issues(that flux solve) in real project you can easier to understands the benefits of the flux, but exactly of this(cause I faced with these problems at work project) now I try to use flux in every project, because I don't wanna to deal with it anymore.
And crazy part, that now I often use it also for ui states, not just data changes. Let's pretend I can have a widget component, for example a clock. It can make some ui changes, like show/hide seconds, switch between digital/analog and it has a daytime type state(day/night) and can dispatch an event when it changed, but other component listen it and can react, for example change a background color. I can easily solve it just with local component state and container(smart component) state, but same as I can put all these logic into store(reducers) and components will be really dump and just react on the current state(props) and containers(smart) just listen the store and partitioned state between the components. And if even it looks ok, point that I can use it for every ui state - open/close sidebar, some specific component changes, etc.
Reasons why I can do it:
It looks predictable for me. I completely know that any changes happened in my app serve in one place.
It easy to debug. I can just log all the actions and if I will get some bug, I can easily found what happened and reproduce it.
I can easily expand my app without worrying, mb I should move something to the flux state, cause I already did it.
But also I agree that it's looks overwhelmed and I can solve it without flux, but I can't answer to me, why I shouldn't use flux in these cases. What is wrong with it? Please help me.
Related
I was attracted to Fyne (and hence Go) by a promise of thread safety. But now that I'm getting better at reading Go I'm seeing things that make be believe that the API as a whole is not thread safe and perhaps was never intended to be. So I'm trying to determine what "thread safe" means in Fyne.
I'm looking specifically at
func (l *Label) SetText(text string) {
l.Text = text
l.textProvider.SetText(text) // calls refresh
}
and noting that l.Text is also a string. Assignments in Go are not thread safe, so it seems obvious to me that if two threads fight over the text of a label and both call label.SetText at the same time, I can expect memory corruption.
"But you wouldn't do that", one might say. No, but I am worried about the case of someone editing the content of an Entry while an app thread decides it needs to replace all the Entry's text - this is entirely possible in my app because it supports simultaneous editing by multiple users over a network, so updates to all sorts of widgets come in asynchronously. (Note I don't care what happens if two people edit the same Entry at the same time; someone's changes will be lost and I don't care who's. But it must not result in memory corruption.) Note that one approach I could take would be to have the background thread create an entirely new Entry widget, which would then replace the one in the current Box. But is that thread safe?
It's not that I don't know how to serialize things with channels. But I was hoping that Fyne would eliminate the need for it (a blog post claims it does); and even using channels I can't convince myself that a user meddling with a widget in various ways while some background thread is altering it, hiding it, etc, isn't going to result in crashes. Maybe all that is serialized under the covers and is perfectly safe, but I don't want to find out the hard way that it isn't, because I'll have no way to fix it.
Fyne is clearly pretty new and seems to have tons of promise, but documentation seems light on details. Is more information available somewhere? Have people tried this successfully?
You have found some race conditions here. There are plans to improve, but the 1.2 release was required to get a new "BaseWidget" first - and that was only released a few weeks ago.
Setting fields directly is primarily for setup purposes and so not expected to be used in the way you illustrate. That said, we do want to support it. The base widget will soon introduce something akin to SetFieldsAndRefresh(func()) which will ensure the safety of the code passed and refresh the widget afterward.
There is indeed a race currently within Refresh(). The use of channels internally were designed to remove this - but there are some corners such as multiple goroutines calling it. This is the area that our new BaseWidget code can help with - as they can internally lock automatically. Using this approach will be thread safe with no changes to the developer in a future release.
The API so far has made it possible for developers to not worry about threading and work from any goroutines - we do need to work internally to make it safer - you are quite right. https://github.com/fyne-io/fyne/issues/506
I'm struggling to persist my state machine following the recipes and examples available. I'm working with the master branch and my state machine uses Hierarchical States, Regions and Orthogonal states. The first example I followed is spring-statemachine-samples/persist but it seems to deal only with basic FSM. The second one I tried is LocalStateMachineInterceptor but id does not seem to be working with Hierarchical States. Also, I can't find any way to persist an history state via a StateMachinePersist.
Is there an example of a complex FSM with persistence anywhere?
I have to be honest that persistence is one relatively unknown topic for samples and docs when things gets more complicated. It is something I'm currently working on to make it easier because as a user you should not care as there should be a relatively clean API's to do it. So stay tuned for those.
Having said that, before we get code more clear on this;
StateMachinePersist leads to StateMachineContext and there is some code in tests, namely StateMachineResetTests which shows some ways to do these things. There was also a question gh127 where I wrote something about internals of resetting a machine which is what a persistence does.
History state, yes that's my bad, for some reason it has slipped from my radar. Thanks for pointing it out! Created an issue for it gh182.
My React app has become incredibly laggy, and I'm trying to find (and destroy) the bottlenecks. The app updates every 10 seconds. And right now, that update is taking >100ms, which is too long.
When I went to record a timeline with the Chrome dev tools, I found that something called "Mixin.perform" was taking 107 ms. Screenshot attached.
This part confused me. Normally, I'd aim to fix whatever appears to be taking the longest. But my app doesn't have any mixins, that I know of at least. It's all written in ES6, so mixins aren't even possible.
I do use some third party components, so maybe it comes from one of those - is there any way I could tell which mixins are slowing things down? Or is there a different explanation?
The Mixin object is part of the React source code: https://github.com/facebook/react/blob/master/src/shared/utils/Transaction.js#L77
There is some description there as to what it's for. I understand it to mean it that is helping preserve state during reconciliation, the technique React uses to make rendering React applications performant enough for production use, and not just theoretically speaking.
You can read about reconciliation here:
https://facebook.github.io/react/docs/reconciliation.html
It's likely that many of your components are receiving props changes, causing re-renders, which will bubble down to their children. At the end of this cycle, React will do its thing and will call Mixin functions to help with reconciliation.
You can try to add some logging information in componentWillReceiveProps or shouldComponentUpdate to compare nextProps with this.props. There may be times when you want to return false in shouldComponentUpdate, which will reduce the amount of work React core has to do. You may also find components are receiving new props many more times then you expect.
This article helps somewhat when trying to understand why components are updating when you think they should not be:
https://facebook.github.io/react/blog/2016/01/08/A-implies-B-does-not-imply-B-implies-A.html
Good luck!
I look that the signature of umbraco.content.AfterUpdateDocumentCache event uses umbraco.cms.businesslogic.web.Document object. Unfortunatelly it is deprecated in "Umbraco 7".
What is the new event?
I'm the same issue in umbraco.content.AfterClearDocumentCache event.
Thanks
It doesn't appear there's any analog for umbraco.content.AfterUpdateDocumentCache in the umbraco7 code.
It seems you may have to reconsider you implementation approach to the available events hanging off Umbraco.Core.Services.ContentService
Looking at the u7 implementation of ContentService.Publish, for example, this call the internal SaveAndPublishDo which shows that the PreviewXML and the ContentXML disc caches are called before firing the Saved and Published (via Umbraco.Core.Publishing.PublishingStrategy) events. I presume the old umbraco.content.AfterUpdateDocumentCache was a single event that happened after both of the aforemented events. In it's absence - i believe you may have to watch for the saved/published/deleted events separately.
I can see that there are a bunch of events that would cause the cache update and it'd be a pain to wire them up separately - but maybee a different approach specific to the granularity of the available events is an upgrade?!
It may also help to backtrack from Umbraco.Core.Cache.CacheRefresherBase where i see there are events like OnCacheUpdated. They exist end do fire - though i'm not sure if or where they are publicly exposed.
This is probably more appropriate as a comment (i need more pts) as it's not a 100% resolution to your question. Hopefully it may be helpful to nudge in the right direction?
http://issues.umbraco.org/issue/U4-3462
According to this thread, answered by members of the Umbraco team, the AfterUpdateDocumentCache should still be used and the deprecated parameters are safely ignorable
I decided to use AfterUpdateDocumentCache in Umbraco 7 but noticed two issues. First of these is double firing this event. Second problem is that I retrieve the same not modified content when rendering page just in this event.
Then I decided to use CacheRefresherBase and CacheUpdate event but still have the same problem. Probably due to additional cache refreshing propagation.
The only workaround I see is to use Thread.Sleep in the new Task and perform purging url a little bit later.
I have a question about best practice on how to tackle a new project, any project. When starting a new project how do you go about tackling the project, do you split it into sections, start writing code, draw up flow diagrams.
I'm asking this question because I'm looking for advice on how I can start new projects so I can get going on them quicker. I can have it planned, designed and starting coding with everything worked out.
Any advice?
Thanks
Stephen
It all really depends. Is the project for controlling a space shuttle with 200+ people working on it, or is it a hobby project with 1 person.
I'm guessing this is a small project. In that case, do whatever works for you. Write a list of things you think are required. If there are parts you know you need to learn more about or research, get reading the web, try some stuff out with prototype code to see whether it works or not. Don't turn prototype code into real code though, start again with production code and make sure you get all the appropriate error handling etc in.
When you think you've got a good feel for what's needed, get coding. If you hit a point where you think it's not working, go back to the design and rethink it and sketch some more diagrams, and then go back to the code again.
It is extremely doubtful that you can work everything out in your plan and that's how things will actually work out. So, there's little point in trying to plan too far ahead because you'll be wasting time. Just plan out far enough ahead to keep yourself focused on working on the right things and so that you've given yourself a reasonable chance that the code you're working on will fit the big picture and solve the problem you're trying to solve.
Start by writing a simple functional spec, a few paragraphs from the user's perspective: what they see, how they perform actions, what they expect to happen if they click widget X. This will glue the logic together in your head, and on paper.
From there you can work on the technical spec, which details the gritty things like database structure, special controls and components you need, SDK's if any, and all other developer-type details that you need to implement.