Real-Time Web Analytics Dashboard with NodeJs, Socket.io, and VueJs
coligo.io
coligo.io
So you pretty much end up with the same level of complexity as more complicated solutions in the real world context.
I learnt it/redux/react-router on Saturday.
The hard parts always figuring out what goes in the store and what you should just handle in your presentational components
the gyst is, you have your state [Redux store] which is updated through reducer functions. Each reducer tracks the state for its part of the system, and is called with an action name+data when the state should change.
actions are called through a function, dispatch. it is typical to run a function as it's input, dispatch(makeAction()) where makeAction does things like make a REST request.
the state object is passed into React components as state and properties, which you can use for rendering HTML. to receive them, you register what you want from the reducers, and it is automagically passed in, and you can pass properties down to child components as HTML looking markup.
when something happens, like a user types into a text box, you call dispatch with the new text to be added to the state, which then gets reduced and passed into the next render call of the component, to update what's shown in the text box.
specific to that codebase, containers are top level components.
routing is done as a React component, where you render a tree of possible routes, pulling out variables as you go, to feed into the component/container leaves, and the matching route is rendered.
[1] https://github.com/choonkending/react-webpack-node [2] https://github.com/jhedin/little-libraries
2. BOTH react and Vue can be learnt in a day
3. BOTH can seem daunting when you're making production app (Vuex, redux, webpack, Vue-router, react-router...)
So, I don't not agree with 'learning curve' that's thrown at React. Both Vue and React are amazing. If you want to use them properly, you as a developer has to spend the time to learn.
Facebook really should have named the Virtual DOM something different to avoid this confusion. The "Virtual DOM" is not an alternative to the DOM (which would be impossible), it is just a string diffing algorithm to minimize the number of DOM mutations required.
2 and 3 are entirely subjective.
Disclaimer: I'm the author.
<input type="radio"
name="branch"
:id="branch"
:value="branch"
v-model="currentBranch">
<label :for="branch">{{branch}}</label>
The Heroku instance is currently overwhelmed with all the traffic. You can download the code from the GitHub repository here: https://github.com/coligo-io/real-time-analytics-node-socket...
and run it using: node app.js
If you can block them (ie: the user needs to login), you don't need to wrory.
It's really common for web sockets not to work through corporate content filters and old load balancers.
Not Microsoft. It's unsupported as of 2 months ago.
Were you able to implement auto-reconnect with backoff? That's one of the most important features that something like Socket.io gives you.
- Events / actions as main abstraction.
- Support for degradation for old devices, browsers, corporate networks.
- WebSocket is not very good at multiplexing. One discrete TCP connection per socket (opposite direction of what HTTP/2 is going)
- Binary support inside JSON (`Buffer` etc)
A lot of people look at SocketIO as a client-side only library, but it's not. It has connection implementors written on the server side to support things like multiplexing over one channel.