<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Flux on Minko Gechev&#39;s blog</title>
		<link>https://blog.mgechev.com/tags/flux/</link>
		<description>Recent content in Flux on Minko Gechev&#39;s blog</description>
		<generator>Hugo</generator>
		<language>en-us</language>
		
		
		
		
			<lastBuildDate>Sun, 10 Apr 2016 00:00:00 +0000</lastBuildDate>
		
			<atom:link href="https://blog.mgechev.com/tags/flux/feed.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>Scalable Single-Page Application Architecture</title>
				<link>https://blog.mgechev.com/2016/04/10/scalable-javascript-single-page-app-angular2-application-architecture/</link>
				<pubDate>Sun, 10 Apr 2016 00:00:00 +0000</pubDate>
				<guid>https://blog.mgechev.com/2016/04/10/scalable-javascript-single-page-app-angular2-application-architecture/</guid>
				<description>&lt;p&gt;&lt;em&gt;In order to have better understanding of the following blog post you should be familiar with the fundamentals of the &lt;a href=&#34;https://en.wikipedia.org/wiki/Software_design_pattern&#34;&gt;object-oriented&lt;/a&gt; and functional programming. I also strongly encourage you to explore the &lt;a href=&#34;http://redux.js.org/&#34;&gt;redux pattern&lt;/a&gt;.&lt;/em&gt;&lt;/p&gt;&#xA;&lt;p&gt;A couple of months ago I started working on the first version of a Silicon Valley-based startup. The project is a single-page application with quite dynamic business requirements. As in most modern single-page applications we have a fat client which encapsulates decent amount of business logic and state.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Flux in Depth. Store and Network Communication.</title>
				<link>https://blog.mgechev.com/2015/07/18/flux-in-depth-store-network-communication-services/</link>
				<pubDate>Sat, 18 Jul 2015 00:00:00 +0000</pubDate>
				<guid>https://blog.mgechev.com/2015/07/18/flux-in-depth-store-network-communication-services/</guid>
				<description>&lt;p&gt;This is the second, and probably be the last, blog post of the series &amp;ldquo;Flux in Depth&amp;rdquo;. In &lt;a href=&#34;https://blog.mgechev.com/2015/05/15/flux-in-depth-overview-components/&#34;&gt;the first post&lt;/a&gt; we did a quick overview of flux, took a look at the stateless, pure components, immutable data structures and component communication. This time, we&amp;rsquo;re going to introduce the store and how we can communicate with services through the network via HTTP, WebSocket or WebRTC. Since the flux architecture doesn&amp;rsquo;t define a way of communication with external services, here you can find my way of dealing with network communication. If you have any suggestions or opinions, do not hesitate to leave a comment.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Flux in Depth. Overview and Components.</title>
				<link>https://blog.mgechev.com/2015/05/15/flux-in-depth-overview-components/</link>
				<pubDate>Fri, 15 May 2015 00:00:00 +0000</pubDate>
				<guid>https://blog.mgechev.com/2015/05/15/flux-in-depth-overview-components/</guid>
				<description>&lt;p&gt;This is the first blog post of the series &amp;ldquo;Flux in Depth&amp;rdquo;. Is this &amp;ldquo;yet the another flux tutorial&amp;rdquo;? What I have seen so far, while researching flux, were mostly &amp;ldquo;how-to&amp;rdquo; tutorials (usually with todo applications), which describe the main components of given flux application and the data flow between them. This is definitely useful for getting a high-level overview of how everything works but in reality there are plenty of other things, which should be taken under consideration. In this series of posts I will try to wire theory with practice and state &lt;em&gt;my own solutions&lt;/em&gt; of problem I face on daily basis. Since these solutions might not be perfect, I&amp;rsquo;d really appreciate giving your opinion in the comments section below.&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
