<?xml version="1.0" encoding="UTF-8"?> | |
<csv-inputs xmlns="http://axelor.com/xml/ns/data-import" | |
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" | |
xsi:schemaLocation="http://axelor.com/xml/ns/data-import http://axelor.com/xml/ns/data-import/data-import_5.4.xsd"> | |
<!-- IMPORT DU PACKAGE 'AUTH' --> | |
<input file="auth_permission.csv" separator=";" type="com.axelor.auth.db.Permission" | |
search="self.name = :name"/> |
BEGIN { | |
int visited[node_t]; | |
int visit(node_t n, edge_t e) { | |
if (visited[n] == 0) { | |
visited[n] = 1; | |
for (e = fstin(n); e; e = nxtin(e)) { | |
visit(e.tail, NULL); | |
} |
;nyquist plug-in | |
;version 1 | |
;type process | |
;name "Subliminal..." | |
;action "Subliminal..." | |
;control carrier "Carrier" real "Hz" 17500 14000 20000 | |
(setf carrier (max 14000 (min carrier 20000))) | |
;; We have two Nyquist frequencies, carrier/2 and *sound-srate*/2. |
Stephen Toub, Microsoft February 2012 Original
Keeping API calls decoupled from React components keeps your views pure and without side-effects! This makes it easier to test your views without having to worry about API calls. You can test your API separately from your views.
Before I dive any deeper, here are some assumptions: You are using React to render your views (HTML). You are using Redux, or something similar to handle state. Myself, I actually use Preact and Atom instead of React and Redux -- They are both much smaller and their source codes are easy to understand, which I favour. The APIs are basically the same. And, I'm also assuming you rely heavily on Redux/Atom and not on React's setState
method.
If you're coming from MVC, then you know your views should be simple and without complex logic. Instead, you would use the Controller to load remote data and do any normalization. But where is the Controller when using React and Redux? There isn't really a controller, but that
/* | |
Everything with no dependencies comes first. That way, when a new item is added with a dependency on an existing item, it doesn't cause the existing item to jump. | |
Of course an existing item taking a dependency on an existing item will cause a jump, may as well move the changing item. | |
An existing item taking a dependency on a new item will also jump. It doesn't really make sense to putting the new item first, out of order, if it doesn't have dependencies. | |
Basically: order by depth_of_deepest_dependency, original_order | |
*/ | |
with | |
creating_objects as ( |
Code review one person reading over another's code and offering comments, suggestions, and feedback about how it could be improved. Often this is done at companies or in open source projects as a required step before proposed changes can be merged into a
If you setup a Rails 4 app, you’ll notice the app/models/concerns and app/controllers/concerns directories. Concerns are modules that can be mixed into your models and controllers to share code between them.
Some developers falsely classify mixins as composition when they are actually a form of inheritance. When you include a module in a class, that module’s methods are added to the inheritance chain just like a parent class’ methods are added to a subclass. So, don’t think you’ve solved the problem of inheritance by simply splitting your inherited code into separate files!
That being said, mixins can be a valuable tool to share code between classes that are otherwise unrelated. Here’s an example of how I chose to use it recently.
I am adding admin reporting features to an app I’m hoping to launch soon. I have an admin controller with a simple before filter to redirect if the current user is not an administrator.
class AdminController < ApplicationController