I have a pretty customized version of a the Perspective table, that includes a lot of convenience features for my client that aren’t built into the native table.
I have a use-case that would require me to be able to put that same table inside of its own subview if enabled, essentially I need it because one table could dynamically generate the need for nested sub-tables with the same functionality.
However, perspective doesn’t seem to like my idea as much as I do
I was curious if anyone has any ideas how I could do this without having to keep a totally different copy of the view just for nesting inside of itself. That would be pretty annoying for managing any customizations that are made to the view and ensuring they are done on both.
I know from a React standpoint this is possible, I am just curious if there is an explicit reason that this can’t be possible from a Perspective standpoint?
Could you try it with a pass-through view? Just a simple embedded view that takes a view path (back to your table view) and passes a params structure. You’d have a second view in your structure, but only one view to develop. I’m not sure this will work but seems like an easy enough workaround to consider testing.
A nuisance this actually created, maybe a room for improvement, is that It required me to move the scripting from my transform out into a project script, and essentially indirect the transform directly into the project script.
This is nice from a version control standpoint, as now its just plain python code, and it can be reused easier, but Its a bit annoying to lose the visibility of things like the view property browser and being able to directly change aspects of the code without having to leave and go into the project scripts.
It would be nice if there was an easier link between project scripts and script transforms. Could be cleaner for Version control long term, as well as make it easier to reuse transform code without making it harder to manage.
That is not possible as it would create an infinite loop of nesting.
you could make one view for the template table, with all the view params binded to its props (among which the viewpath of the subview) Im quite sure you should then be able to make an embedded view with both the viewpath and subview path pointing to the same template. Tho i have not tested that
This is not really an inherit limitation of React though which is what perspective is built on, Yes you could technically create an infinite loop if you weren't managing the number of instances that nest into each other, which is my guess as to why they put this safeguard there in the first place. But if you develop the view in an effective way than you can ensure that you only ever nest one level deep
As an example, even something as simple as having a property on the view, that when it is set to true it disables the subview. Then providing that as a parameter to the subview on the main table itself
