These are chat archives for jdubray/sam

18th
Jul 2016
Vincent Jo
@chiwoojo
Jul 18 2016 01:10
@jdubray hey JJ, I hope you are well; I had a question about display function
so I implemented a search results filtering function
on my app
and neither the search query nor the filtered results are saved in the model
everything is handled at view component level...
I remember that's what you suggested last time so I tried that... I could be wrong though
so, now I'm calling display function like this
blob
and setup looks something like
blob
and the setUpSearchInputComponent function sets up the onchange handler on the <input> tag
and also filters the search results function
one question I had was if it's okay to pass in additional parameters for display function
and another question was if I'm doing okay by putting the filtering logic inside of the component
thanks JJ
Jean-Jacques Dubray
@jdubray
Jul 18 2016 02:59

@chiwoojo It really depends how you see the responsibility between the component and state representation. Sometime you have components that can sort/filter the data. There is no need to return to the model. You are not updating the application state/model or the state representation (you remain logically in the same state). Sure could argue the model should know everything there is to know about the application state, but that's a bit extreme IMHO.
SAM is just about creating "buckets" with clear roles and responsibilities but there is not one answer fits all, as long as you have a logical reason to put some logic in one bucket and not another.

it's okay to pass in additional parameters for display function

I assume you are talking about config parameters? in that case, yes of course, you may also use closures to do that. It's ok to maintain state in the component as long as it is not "application state". For instance a sort order might be kept in the component, but I would not keep it in the state representation. The only kind of values I would keep in the state representation are highly static like config parameters. They would not fit well in the model because you would want to model to work with different state representations.

Jean-Jacques Dubray
@jdubray
Jul 18 2016 09:20
This message was deleted
Vincent Jo
@chiwoojo
Jul 18 2016 15:58
Hi JJ, thanks for your answer; I read over it and had some question on what you meant by a config parameter?
the 'setup' param I pass to the display function is an object that has key as the name of the function such as 'search-results-setup'
and the value for that is a function itself
so util.setUpSearchInputComponent is like:
    setUpSearchInputComponent() {
        const searchInputEl = document.getElementById('searchInput');
        if (searchInputEl) {
            searchInputEl.oninput = () => {
                // get content of input
                const searchInput = searchInputEl.value;
                const rows = document.getElementById('search-results-table').rows;

                for (let i = 0; i < rows.length; i++) {
                    const row = rows[i];
                    const titleField = row.children[0];

                    if (titleField.innerText.includes(searchInput)) {

                        // hightlight search results
                        titleField.innerHTML =
                            titleField.innerText.split(searchInput).join(`<a>${searchInput}</a>`);
                        row.style.display = 'table-row';
                    } else {
                        row.style.display = 'none';
                    }
                }
            };
        }
    },
it binds a oninput handler
so I wonder if this falls under config?
Vincent Jo
@chiwoojo
Jul 18 2016 16:03
but generally it seems like it would be okay to keep some logic in the component that doesn't need to necessarily belong to the application state
Edward Mulraney
@edmulraney
Jul 18 2016 17:27
@jdubray what's a real world example of a unit of work that doesn't result in a model mutation?
Jean-Jacques Dubray
@jdubray
Jul 18 2016 17:42
@edmulraney The model should be dedicated to handling mutations. If some business logic do not result in mutation (I am not talking about rejecting proposals), then it would be best to keep it outside the model. Do you see use case?
You could think about something like "logging" (say business logging). Then it would be better to handle it in the action because it's a long running operation.
@chiwoojo you can keep any view related logic in the component.
Fred Daoud
@foxdonut
Jul 18 2016 19:41
@mnichols are you still around?
if so, what's the latest in your adventures? on my side, I've been having a really hard time with Meiosis-Riot integration. I can't get Riot to do what I want.
which is to 1) initialize tags with a propose function or an actions object; and 2) have a single state tree (root model) at the root tag and have it passed down to children.