Comment for Dataflow

[HamzaFractl]

For discrimination mechanism for maps inside a dataflow pattern to display relevant badge on the frontend i.e. display Upsert Instance of Upsert Instance map, Query for Query map

[vijayfractl]

A trivial way to detect pattern types is given below:

1. if pattern is a map and contains a key that ends with a ? (e.g :EmployeeId?) - it's a query pattern, otherwise it's an upsert pattern
2. if pattern is a vector and starts with one of [:match :try :for-each :query :delete :await :eval :entity] - it's a built-in command

To solve (1), the walk function may be used (https://clojuredocs.org/clojure.walk/walk).

A proper way to solve this issue it to abstract the syntax behind a higher-level API. This will be handled in issue #636 @fractlrao @HamzaFractl @puneet-fractl

[HamzaFractl]

I have discussed a :content approach with @puneet-fractl. The :content will contain array of maps which will store the data in this type of map {:name "Upsert/Query/Loop" :map "which will store the map" :id "uuidv4 "} . By using this approach the map will be easily inserted or deleted using :id which I will generate on the frontend. This :content value will be of no use for backend as it is only usable for frontend only. Backend is concerned only with the information of maps which I can compile easily by doing the map (map (fn [dataflow-map) (:map dataflow-map)) :content dataflow). By using this approach I will be able to discriminate betweeen the maps of dataflow even before the map is compiled by selecting values from the frontend.

[vijayfractl]

The :content approach will work for dataflows designed in the frontend - what about imported dataflows? Also, in the design studio, the patterns are generated directly in the syntax of fractl - any change in syntax - the frontend has to be updated. The approach given in #636 tries to solve both the pattern identification and code-generation problem by wrapping the syntax under a convenient API.